commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: [lang][collections] Overlap; Collections thoughts
Date Sun, 03 Jan 2010 17:20:07 GMT

On Jan 2, 2010, at 3:27 PM, Henri Yandell wrote:

> On Sat, Jan 2, 2010 at 10:45 AM, Phil Steitz  
> <> wrote:
>> Henri Yandell wrote:
>>> 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.
> Agreed that it's a bad example. I'd used it as a component that had
> left collections for some reason and might be a better fit - not from
> a technical perspective. My negative to adding to Lang would be that
> unlike the Enum and NestedException pieces of code, functional-in-OO
> needs a lot of language support to feel good.
>>>>  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.
> Lang's math.NumberUtils and math.Fraction for example. MathUtils and a
> little bit of StatUtils do look to be similar in scope.
> The special bits with collections are:
> * Lang issues are identifying overlap problems with Collections.
> ArrayUtils starts to look like Collections when you take a more
> generic approach to a problem (for example ArraySet),
> ComparableComparator was recently copied over (private class) and
> there is a ComparableUtils class request.
> * I have concerns over whether there will be a Collections 4.0.

My view on this is "eventually"--I certainly feel I've put in too  
much work to simply let [collections] go.  However, the following  
issue you identified has been a thorn in my side for quite some time  
so I am on board for streamlining, multiple artifacts, and anything  
else that will improve the situation.

> * Collections has issues that say (paraphrasing) "Nice idea, don't
> commit until Collections is lighter in weight".
> * Collections has more code at the JDK level being hidden by more
> additional features than say IO (less additional features), Codec (not
> a lot of JDK level code), Math (not a lot of JDK level code).
>>>> 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?
> I thought the new reflect package was from BeanUtils. I think by way
> of the reflect sandbox component. If not code from BeanUtils, it is a
> direct overlap with some of the code at the core of BeanUtils.

That code was indeed cloned/copied from BeanUtils.  The [reflect]  
component in the sandbox didn't figure into the pedigree, though some  
of the class names there would understandably suggest otherwise (or,  
for all I know [reflect] may have also been cloned from BeanUtils  
code).  The point being that oacl.reflect provides a thin veneer over  
java.lang.reflect and thus seemed to be a proper fit.


>>>> 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].
> Taking things to the logical conclusion you suggest (lots of
> components pushing down into [lang]) would definitely end up with
> [lang] as a low level dependency of all. Nice in some ways, not in
> others. We could definitely use a jarjar type thing there if we got
> serious on the subject.
> In terms of things depending...
> Removing comparators from Collections would leave PriorityBuffer and
> TransformingComparator both wanting ComparableComparator. Lang also
> uses that - given that java.lang.Comparable fits in Lang and
> java.util.Comparator is taken to fit in Collections I think the
> overlap problem here is 'fine' - i.e. outside our control. This is the
> main part I began with.
> For Iterators - I agree. The same would be true of the various
> XxxUtils classes. How much does the rest of Collections depend on
> them. I suspect the painful part would be the most useful bits, rather
> than idiosyncrasies. There are also features that I think are less
> useful and more theoretical. ArrayListIterator on top of ArrayIterator
> - driven more by the concept of ListIterator and ResettableIterator
> (imo).
> Hen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message