commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [lang] Designs and Futures
Date Tue, 01 Jun 2004 23:46:20 GMT
There are two areas that I see commons as poor at achieving - release early
release often and dependencies. The code itself is generally very good
(despite what some might say).

[lang] is an example of this. It has needed a release for some time, if only
to fix some of the glaring bugs in 2.0. It has also had changes applied to
it that increase dependencies.

I know that many reading this don't get my point here. Perhaps if I used the
word coupling instead that would help? In the Validate case, there is no
need for Validate to be coupled to StringUtils and ArrayUtils. It wasn't in
its original design, I was just reverting code back to 2.0.

This extends to other packages - ideally, no subpackage within lang should
depend on another. We won't achieve that, but it should be a basic goal. (It
should be noted that in [collections] I introduced more
dependencies/coupling between classes in v3.0 and it has since been shown to
be a Bad Thing)

As I've tried to explain elsewhere, [lang] is not one jar file but many. It
is a place where these tiny pieces of code can be grouped together and
looked after, because even smaller projects tend not to work. After all, we
ought to be able to create an exception jar, or an enums jar, or a validate
jar if we wanted.

Finally, it should be noted that [lang] has about 30 open calls, and many
are valid. This suggests a wide user base who want this component supported
and improved. The issue for us is more to do with [lang] satisfying our own
personal isues already, so we don't feel motivated to do anything about it -
its not our itch any more. But somehow, we need to at least get 2.1 out,
then take it from there.

[lang] is actually a great achievement, as almost certainly the most widely
used library of its type. Lets not loose that achievement.


----- Original Message -----
From: "matthew.hawthorne" <>
> Gary Gregory wrote:
> > Sorry for the flame but this is a 'shake-my-head-in-disbelief' moment
> > that I find discouraging.
> I pretty much agree, but from my POV [lang] stopped moving forward a
> while ago anyway.  Most new requests
> or ideas are rejected as "out of scope" (which is usually valid), and
> the project has shifted into
> maintenance mode.  Along with this came a certain identity crisis, and
> that's why the cut-and-paste
> philosophy came along.
> As another example, I've never even liked the public constructor in
> *Utils classes, even though I understand why it's
> done.  Helping and supporting users is important, but I think there is a
> certain line that has to be drawn.
> I think that developers should have the freedom to make classes and
> methods final where appropriate,
> and make other design decisions that may limit the possible uses of the
> library.  In losing that ability, I believe that
> the quality of the code suffers.  And for someone like me, it makes me
> less motivated to become involved or share ideas.
> I may be dead wrong, these are just some feelings that I have.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message