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 18:45:24 GMT
Henri Yandell wrote:
> On Sat, Jan 2, 2010 at 9:11 AM, Phil Steitz <> wrote:
>> 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].
> Agreed - both in terms of what we consider a simple extension of the
> JDK and what we consider a data structure/algorithm.
>>  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 ;).
> I was thinking more that a smaller [collections] might have room for
> the functor code again - not that [lang] would :) Agreed that it's
> better out than in though.

That is instructive, but sort of hurts the case, though, as functors
are arguably closer to a language extension than they are related to
the [collections] domain.

>>  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]?
> has a bit.
> The various XxxUtils classes - but not the factory builder parts that
> supply various aspects.
> A slice of the iterators and the comparators. Possibly some basic
> 'missing' implementations such as ArrayStack, ArraySet, FastVector
> etc.

So its the bits that connect the domain to the JDK?  That would put,
for example, parts of o.a.c.math.stat.StatUtils,
o.a.c.math.util.MathUtils similarly in scope.  The question here is
what is special about [collections] and doesn't this just amount to
artificially hacking off pieces that belong with the domain?  I am
still not seeing the "joints" here.

> Not in scope - bag, buffer, transformer,
>> 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.
> [io] and [codec] are the ones that jump to mind for me, but I think
> they're both still tight enough in scope that a) the committer style
> is not different and b) it's not a big brain import for the users to
> grok the component. Again though there's a similar style of FooUtils
> classes  on top of the JDK mixed with SPI type implementations.
> [beanutils] always feels like it needs replacing - something smaller
> and tighter in [lang] could be a successor.
>> 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.
> Yup. We've already been doing it with BeanUtils - some of the code
> moved/copied over in 3.0.
> What it would possibly mean in your commons wide suggestion is a bunch
> of components having a dependency on [lang], which as you say below
> has often been a blocker. Then again - all java.* code depends on
> java.lang.* :)

Can you explain a little more what exactly has moved from BeanUtils
and what kinds of other things you have in mind?

>> 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.
> Yup. Effectively this is both a split into 'Collections JDK' and
> 'Collections Structures', and a merge of Collections JDK to Lang.

A natural question to ask is is that the best way to split
[collections] up?  It would probably force some users to depend on -
and look for stuff in - [lang] when [collections] by itself would
now meet their needs.  Pulling the iterators, for example, out of
[collections] would make it harder to use by itself and I bet would
force [collections] itself to depend on [lang].  I am not (yet)
convinced that this is the best way to divide [collections].

> To Paul's email - I think a wholesale merge of Collections and Lang
> would be too much. It would slow down releases when we need to release
> more often (that being part of my justification for splitting
> Collections - the two halves would be quicker to release). I think
> that  similarity of scope within a component makes it more releasable
> - the hardest part of Lang 3.0 is the builder subpackage, and I think
> that's because it's a different style of code than much of the rest.
> Hen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message