commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [lang][collections] Overlap; Collections thoughts
Date Sat, 02 Jan 2010 17:11:10 GMT
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.

Interesting idea and forces us to really think about the scopes of
both [lang] and [collections].  Both started as really extensions of
the JDK and both have had large parts obsoleted by advances in the
JDK.  I guess it still makes sense to consider [lang] as simple
extensions of the JDK and [collections] as data structures.  What I
have a little trouble with is where to draw the line within
[collections].  I think functors is a bad example, as one could
argue that this belongs in neither [collections] nor [lang] - oh
wait, we did that and created [functors] (lets not divert down that
rabbit hole ;).  Better examples of what might be peeled off into
[lang] could be the iterators or decorators.  Can you get a little
more specific on what parts of [collections] you see as in scope for
 merging into [lang]?

I am +1 on publishing the collections test jar as a separate maven
artifact.  We don't have to create a separate subproject for that, IMO.

Note that lots of other commons components - [math], [net],
[functors], [configuration], [beanutils] all come to mind
immediately - have elements that amount to extensions of the JDK.
Like [collections], they all have a more specialized domain that is
their primary focus.  So the natural question is, if this makes
sense for [collections], why not everywhere else?  Answering that
question might help clarify intent here.

One final comment is that a logical alternative is to just split
[collections] internally into multiple pieces with separate release
cycles. Managing dependencies among the subcomponents and user
documentation might be tricky.  IIRC, that is what has prevented us
from actually ever doing this up to now.


> Thoughts?
> Hen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message