commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <rwaldh...@apache.org>
Subject Re: [general][lang] monolithic components considered harmful
Date Thu, 02 Jan 2003 18:04:32 GMT
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

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]

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

* 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

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


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.

 - R.

On Wed, 1 Jan 2003, Stephen Colebourne wrote:

> Let me attempt to demonstrate why multiple jars won't work. Imagine we do
> the split of [lang] into jars based on Common Reuse/Reuse-Release
> Equivalence/Common Closure Principles.
>
> [arrayutil]
> ArrayUtils.java
> - depends on [builder]
>
> [booleanutil]
> BooleanUtils.java
> - depends on [numberutil]
>
> [charsetutil]
> CharRange.java
> CharSet.java
> CharSetUtils.java
>
> [stringutil]
> RandomStringUtils.java
> StringUtils.java
>
> [classutil]
> ClassUtils.java
>
> [notifierutil]
> Notifier.java
> NotifierException.java
> - depends on [exception]
>
> [numberutil]
> NumberUtils.java
>
> [objectutil]
> ObjectUtils.java
>
> [serializationutil]
> SerializationUtils.java
> SerializationException.java
> - depends on [exception]
>
> [systemutil]
> SystemUtils.java
>
> [builder]
> CompareToBuilder.java
> EqualsBuilder.java
> HashCodeBuilder.java
> StandardToStringStyle.java
> ToStringBuilder.java
> ToStringStyle.java
> - depends on [numberutil], [systemutil]
>
> [enum]
> Enum.java
> EnumUtils.java
> ValuedEnum.java
>
> [exception]
> ExceptionUtils.java
> Nestable.java
> NestableDelegate.java
> NestableError.java
> NestableException.java
> NestableRuntimeException.java
> - depends on [arrayutil], [systemutil]
>
> [functor]
> Executor.java
> ExecutorException.java
> ExecutorUtils.java
> Factory.java
> FactoryException.java
> FactoryUtils.java
> Predicate.java
> PredicateException.java
> PredicateUtils.java
> Transformer.java
> TransformerException.java
> TransformerUtils.java
> - depends on [exception], [serialization]
>
> [numberrange]
> DoubleRange.java
> FloatRange.java
> IntRange.java
> LongRange.java
> NumberRange.java
> Range.java
> - depends on [numberutil]
>
> [fraction]
> Fraction.java
>
> [reflect]
> ConstructorUtils.java
> FieldUtils.java
> MethodUtils.java
> ReflectionException.java
> ReflectionUtils.java
> package.html
> - depends on [arrayutil], [classutil], [stringutil], [exception]
>
> [timeutil]
> CalendarUtils.java
> DateUtils.java
>
> [timingutil]
> StopWatch.java
>
> [bitfield]
> BitField.java
>
> [identifier]
> IdentifierUtils.java
> - depends on [functor]
>
> [validate]
> Validate.java
>
> So, 22 new commons components. <sarcasm>Now thats a good idea isn't
> it</sarcasm>
>
> And if you think this is pedantic look at the list again. Any combination of
> the above components is combining two concepts that don't have a direct
> connection.
>
> Because thats what [lang] is, and thats why is doesn't fit the holy commons
> charter. Its a combination of useful utilities
> - too small to exist alone (one class)
> - that gain strength by being together (see some of the more unusual
> dependencies above)
> - encourage reuse and discourage cut and paste by offering more (I might cut
> and paste if I want one routine. I might depend if I want more than one. The
> broader range available increases reuse over cut and paste)
> - builds a viable community (not just counting committers, but users. The
> time and math packages are user suggestions. The util package is the useful
> parts of the dead community [util]. The functor package is the useful parts
> of the dead community [pattern].)
>
> Should we complain that the JDK contains stuff we don't use?
>
> Stephen
>
> ----- Original Message -----
> From: "Rodney Waldhoff" <rwaldhoff@apache.org>
> >  Person ${p} suggests feature ${f} for component ${c}. Person ${q} insists
> > it belongs in [lang].
> >
> > and ${q} pulls from a very small set.
>
> and {q} = Stephen
> Rodney, please feel free to make it personal if thats what you believe.
>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message