commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [lang][collections] Overlap; Collections thoughts
Date Wed, 06 Jan 2010 01:58:53 GMT
There are many good points in this thread. My input is to try and 
outline where I have seen te boundaries.

[lang] vs [math] - [lang] doesn't require a maths degree. [math] does.

[lang] vs [functor] - [lang] doesn't require FP knowledge or religion. 
[functor] does.

[io] - handles Stream, Reader and Writer - the package

[collections] - handles those interfaces defined by Sun as the Java 
Collections Framework

[beanutils] - handles code that adheres to Sun's defined Java Bean framewok

[lang] - the remaining parts of java.lang and java.util

Oh, and as per the original commons charter, DUPLICATION IS FINE!
There is nothing fundamentally wrong with small amounts of duplication 
in low level commons classes, and this is far preferable to te 
unacceptable idea of dependencies.

Thus, Fraction can happily live in [lang] and [math] - no great harm 
comes fom it ([math] targets a smaller group of developers than [lang]).

ArrayUtils? Well arrays are not part of the Java Collections Framework. 
So, its fair for array handling code to be in [lang].

And splitting [collections]? Definitely a good idea. I would remove all 
the Predicate/Closure/Transformer code (if you believe in FP, use 
[functor]). Then split the rest by implementations of JDK collections, 
and extended JDK collections - BidiMap, Bag, Trie.


Henri Yandell wrote:
> Overlap between Lang and Collections is starting to increase a bit.
> Requested items for ArrayUtils (LANG-238, LANG-470) are better
> implemented imo as an ArraySet class. An easy add to Collections.
> ComparableComparator made its way (privately) over for the new Range
> class. Fair enough - Comparable and Comparator also overlap between
> lang.* and util.*.
> I have a JIRA issue threat to consider moving Collections code over to
> Lang if Collections becomes dead [LANG-532]  :)
> ---
> One thought I have for Collections is splitting it up into two parts.
> The first would be items that add to collections in the JDK, the
> second would be additional collections. The former could conceivably
> merge with Lang, the latter could also be split up into an SPI style
> approach with an API jar and an Impl jar. The latter would most likely
> depend on the former.
> It would then be tempting to also merge Functors for example into the
> latter, plus I think we could get back on the bandwagon of adding new
> things, like the long standing Trie JIRA issue.
> Biased note: Part of this is that I'm interested in the JDK enhancing
> parts, but not all the implementations of weird and whacky
> collections; however I think this is likely not just me and that the
> separation would do wonders for the release cycle.
> Thoughts?
> Hen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message