commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <>
Subject Re: [lang][collections] Overlap; Collections thoughts
Date Sat, 02 Jan 2010 17:22:16 GMT
I do not like the divide between Lang and Collections. I think it's a
superficial divide that can never really be complete, and the forces
of logic naturally pulls us back together in some regards. It's
consternation to keep these projects separate. Why must we keep

I'd like to propose merging the projects and then breaking them down
into separate Maven child modules (i.e., distribution assemblies). I'd
rather have one release with smaller artifacts. Perhaps we can do this
for Commons Lang 3 (or, if we must, wait till 4).


On Sat, Jan 2, 2010 at 11: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].  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.
> Phil
>> Thoughts?
>> Hen
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message