commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [general][lang] monolithic components considered harmful
Date Fri, 03 Jan 2003 01:28:43 GMT

On Thu, 2 Jan 2003, Rodney Waldhoff wrote:

> Bah. I think you're being willfully obtuse about this.

Possibly, but if your criteria can't be applied to everything then they
are not worth applying [okay, maybe a bit too bombastic].

> The heuristic is to place types that are commonly used or changed
> together, or mutually dependant on each other, into the same component.

I believe this heuristic is akin to the problem of over-modeling. You see
a future problem [enormous lib] and want to solve it now with a minimum
of knowledge. If [lang] grows enormous, I can easily see it evolving to
the structure you describe, but it does not have that size.

> At the risk of getting mired in the details (and just considering the
> stuff currently in lang) here's one such partitioning:
> [functor]
>  - containing things like: lang.functor.*
>  - use this when you need to: treat functions as objects

[functor]'s are about 18 years old it seems. They're not quite ready to
live on their own, but they want to be out there it seems. I am happy to
accept functors [and the name does seem to fit the pattern [see
proposal]] being their own project, but believe they will suffer to start
with. They have sufficient size to overcome the slowness of being a new

One good thing this series of discussions has shown is that there is a lot
of interest in functors. Rodney, Stephen and Costin have all shown
creative input in this set of mail, and the original authors of functors
[Ola? Stephen? Steven? others?] obviously also have shown that input.

It seems that [functor] needs to do some soul-searching. If this were a
company and I were a big-cat CEO [get my shoes Smithers], then I would
suggest [this is why I'm not a CEO, I think I'm meant to demand or order]
that those involved start discussing the next step for functor.

IFF [functor] is to see its scope widen very soon, ie) Costin's ideas,
then it should form its own project. Functor with a lot of mail arguing,
increase in size and a big need for good documentation will quickly become
the pig in [lang]'s belly.

IFF [functor] is seen to be pretty much complete, then it should go into
[lang], to be promoted out IFF it is shown to grow in scope at a later

I'm going to repeat this in another email for brevity.

> [reflect]
>  - containing things like: lang.reflect.*, ClassUtils, etc.
>  - use this when you need to: manipulate objects via reflection and
> introspection

The code is not even finished, and I believe [lang] is still the right
place for it, unless it becomes a religion that coders have to adhere to,
ie) clazz. I doubt it will grow that large.

> [math]
>  - containing things like: NumberUtils, lang.math.*, numerical analysis
> functions like gcd, lcm, isPrime, getFactors, etc.
>  - use this when you need to: manipulate numbers or use numerical
> algorithms

Even with these, which is stretching the limits of math, it will be a
sufficient sub-package. I believe [math] should continue [once it is even
coded] to live in [lang] until such a time as it is big enough to leave

> [datetime]
>  - containing things like: lang.time.*
>  - use this when you need to: work with dates and times

Ditto as for [math], except that I think making a [time] project would be
a waste of time as Stephen has already walked this road and is suitably
licensed (i assume).

> A more fine-grained partitioning might add:
> [string]
>  - containing things like: CharRange, CharSet, CharSetUtils,
> RandomStringUtils, StringUtils, [WordWrapUtils], etc.
>  - use this when you need to: manipulate strings
> [exception]
>  - containing things like: lang.exception.*
>  - use this when you need to: manipulate Throwables, or use nested
> exceptions before JDK 1.4
> or even:
> [assert]
>  - containing things like: Validate
>  - use this when you need to: use assertions before JDK 1.4
> several of the remaining classes *might* logically move to an existing
> component, become the kernal of new component, or simply stay in lang:
> * serialization stuff could move to [io] or to a new [serialization]

I still reckon that Serializable should be in java.lang. Once [io] exists,
maybe this move would be right. As [io] is unlikely to surface soon, I
don't think this should happen for a long time.

> * BitField could move to [collections] (i.e., as a collection of bits) or
> to [math] (for things like unsigned int, unsigned short, etc) or to
> [converter] (i.e., as bit-to-number conversion)

I'm happy for this to happen now. Collections didn't want it when [util]
was broken up before [lang] started. It's been a problem-child.

> ....

> The result is 4 to 7 new components, some of which might reasonably start
> in the sandbox, some of which could be proposed for commons proper
> immediately.  All of these have stand-alone utility, strong cohesion, a
> readily identifiable scope, and few if any inter-dependencies.

-1 to any released code moving to the sandbox on the general principle of
it. Anything that is released should either be deprecated because it has
moved, or deprecated because it is redundant.

Many of these ideas will be applicable this time next year I suspect, but
not now.


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

View raw message