commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <>
Subject Re: [general][lang] monolithic components considered harmful
Date Thu, 02 Jan 2003 20:52:44 GMT
On Thursday 02 January 2003 19.04, you wrote:
> Bah. I think you're being willfully obtuse about this.
> The heuristic is to place types that are commonly used or changed
> together, or mutually dependant on each other, into the same component.
> 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
> [reflect]
>  - containing things like: lang.reflect.*, ClassUtils, etc.
>  - use this when you need to: manipulate objects via reflection and
> introspection
> [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
> [datetime]
>  - containing things like: lang.time.*
>  - use this when you need to: work with dates and times

You are forgetting the case when things in one component needs or would be 
better to utilize things in other components. The functors, the exception 
utilities, Validate etc are extremely useful in all the other components. And 
what do you do when the implementation of Validate utilizes the exception 
utilities, the exception utilities utilizes the reflection package, the 
reflection package utilizes Validate along with some of the functors etc? 
[Circular dependencies alert]

I agree that a full blown math package would be better off on its own, and 
the same applies to datetime, advanced reflection etc. 

But [lang] isn't scoping for the full blown in one field, but for the basic 
stuff in many fields. Basic date/time handling, number ranges, simple 
validation, things that the application programmer needs regardless of the 
application, and things that the components need themselves.

There is nothing that stops a more full blown 
datetime/math/reflection/whatever package. I just don't think that you should 
have to incorporate the full blown when you just need the basics.

> [assert]
>  - containing things like: Validate
>  - use this when you need to: use assertions before JDK 1.4

Well, no. Validate is for input validation. Assertions in JDK 1.4 is 
expressively not for input validation.

> * serialization stuff could move to [io] or to a new [serialization]

I agree with you on that one.

> * 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)

Note the "or" you just used. It indicates that BitFields are useful outside 
of both collections and math, which is an indication that it shouldn't go 
into any of them. Given their general usefulness, I think they fit in lang. 

> * BooleanUtils are by and large, converters like those derived from
> [functor], currently found in [beanutils], or could be part of a
> [converter] component as some have suggested

I disagree. They are very useful outside of the conversion applications. 
Handling a primitive value. Lang will do fine.

> * the methods in ArrayUtils, BooleanUtils and ObjectUtils really just do
> one of the following:
>  - wrap around various builder methods (toString, equals, hashCode)
>  - replace a trivial cast (clone, reverse, identityToString)
>  - implement trivial predicates, relations, or converters (isSameLength,
> isSameType, equals, defaultIfNull, toBoolean[Object], toInteger[Object],
> etc.)
> and could probably be naturally split among the other components
> (including lang) in ways more in line with the common reuse and common
> closure principles.

They are useful for any application doing generic handling of core java 
language elements (arrays, object, boolean/Boolean). Isn't that what [lang] 
is good for?

I put a general discussion on the scope of [lang] in a separate thread.


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

View raw message