commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <>
Subject Re: [primitives][collections] primitive collections and PROPOSAL
Date Thu, 04 Sep 2003 22:00:41 GMT
I wasn't around for any voting or coding on primitive collections, but here's my 2 cents:

Other than adapters, I don't see [collections] and [primitives]/[pcollections] as projects
that have much to share at all.   They seems to have the potential of being 2 separate code
bases, and with the size that [collections] has grown to, I think it's a good choice and opportunity
to split them apart.

>I've already got a significant (and for the record, largely open
>source) body of code dependent on the current implementation and the
>current packaging, as well as a substantial installed user base.
>Repackaging this code to move or remove the word "collections" seems to
>create a lot of trouble with little if any benefit.

Creating dependencies on unreleased code seems like an action that is undertaken "at your
own risk".  In my opinion, that fact that the code is being used in its current form by you,
or anyone else, isn't a good enough argument to keep it that way.

Moving unreleased commons proper code to a sandbox component doesn't appear to decrease the
stability at all.  Both areas are volatile and subject to change without an official deprecation

>The code is well within the scope of commons-collections, so demoting
>it for the sole purpose of removing it from commons-collections seems
>questionable at best.

I agree that the code falls within the scope of [collections], however I also think that it
falls more directly in the scope of a project like [primitives].  I think that keeping the
code together brings the potential of [collections] growing too large.  The amount of classes
needed for [pcollections] is tremendous, enough to warrant a redefinition of the scope of
[collections] to Object-based versions only. 

Is that legal?  Am I making sense?

Rodney Waldhoff wrote:

>On Wed, 3 Sep 2003, Stephen Colebourne wrote:
>sc> From: "Rodney Waldhoff" <>
>rw> > * I'm -1 to moving collections.primitives, or more generally,
>rw> > any release ready code, to the sandbox, as this moves it
>rw> > further away from a release rather than closer.
>sc> I'm balancing this worry with the desire to not release something new
>sc> that is in the wrong place. The basic issue is that primitive
>sc> collections are quite disconnected (ie. totally) from the rest of
>sc> the package. This argues
>sc> for a separate project, as you have done in the
>sc> past over parts of lang (which has happened).
>What I have argued in the past, and I'll argue now, is that cohesive
>components are constructed out of classes that are (a) interdependent, (b)
>commonly used together, and/or (c) commonly change together.  Adapters and
>test suites aside, currently collections.* and collections.primitives.*
>fail the first test but pass the second two.  Of course, many of the
>collections.* classes have this profile, for just one example, LRUMap and
>rw> > a) The two code bases are not truly independent, they share
>rw> > a unit test suite, so if we split the two we'll probably want
>rw> > to extract the shared unit testing framework.
>sc> I would see this as a compile-time dependency on [collections].
>Except that the unit testing framework isn't currently distributed in any
>form.  This is a compile-time (or test-time) dependency on code that's
>currently internal to the commons-collections code base.
>rw> > b) It is quite likely that we'll eventually want primitive
>rw> > implementations of Bag and other commons-collections-only
>rw> > extensions, which would introduce direct
>rw> > collections/primitive-collections dependencies, at
>rw> > least at the adapter level.  This would also imply that
>rw> > collections  and primitive-collections packages are likely to change
>rw> > together, since changes to commons-collections extensions would
>rw> > imply changes to the primitive collections.
>sc> Primitive collections may depend on the Bag interface, but
>sc> probably little else.
>>From a quick glance, Bag, BoundedCollection, Buffer, MultiMap, OrderedMap,
>OrderedSet, PriorityQueue, ResetableIterator, ResetableListIterator and
>SortedBag all seem like interfaces that we'd quite likely want to support
>within the primitive collections sooner or later.  Many interfaces that
>aren't commonly implemented via decorators would likely fall into this
>category as well.  Any change to the object based implementations will
>likely necessitate a change in the primitive implementations and/or their
>sc> This could be solved by adding a [collections] dependency, or by
>sc> simply including the Bag interface in the primitive-collections jar.
>sc> (I know that sounds scary, but an isolated interface, thus
>sc> non-changing, should be fine in two jars)
>This is indeed one approach, but what problem are we trying to solve?
>rw> > * I'm +0 to having the commons-collections component release
>rw> > multiple JARs, for example, commons-collections.jar (everything
>rw> > minus *.primitives), commons-collections-primitives.jar
>rw> > (*.primitives.*),  and
>rw> > commons-collections-all.jar (everything).
>sc> I'm -0.5 to this approach. I think it confuses users
>"Primitive collections are there, object collections are here", what's
>confusing about that?  How's [pcollections] and [collections] less
>confusing, or for that matter, different?
>sc> and leads to classpath issues with the same class in two jars.
>Fair enough, so drop commons-collections-all.jar.
>rw> > * I'm unsure about the notion of "primitives" as opposed to
>rw> > "primitive collections".  Precisely what non-collection stuff
>rw> > do we believe to be in scope for "primitives"?
>sc> Well, comparators aren't actually collections. Plus Mutable priimtive
>sc> wrapper classes are also possibilities.
>Primitive comparators are pretty much defined by the built-in operators
>(either '-' or '<'), and/or by auto-boxing.  (And the most common use of
>comparators is handled by java.util.System methods anyway).
>Currently object-level comparators are in collections, so I don't think
>this is making the problem any worse. (Not that there are primitive
>comparator implementations in the code base currently anyway).  Arguably
>there is overlap with lang, math, collections and functor on this point.
>sc> We copy the existing [collections] primitive code to a new
>sc> sandbox project [pcollections] unaltered except for the package name.
>sc> (I've already tried this locally and it works). (Thus I volunteer for
>sc> this)
>sc> [pcollections] and [primitives] can then cooexist, and Darwin will
>sc> then decide. If you want to push for [pcollections] promotion and
>sc> release,  that will be your call. Alternatively you could wait a month
>sc> or so to see how [primitives] turns out :-)
>Independent of moving the component or jar distributions around, I'm -1 to
>repackaging code from org.apache.commons.collections.primitives at this
>time.  I've already got a significant (and for the record, largely open
>source) body of code dependent on the current implementation and the
>current packaging, as well as a substantial installed user base.
>Repackaging this code to move or remove the word "collections" seems to
>create a lot of trouble with little if any benefit.  I can't imagine what
>else would go into that namespace anyway, so if we're going to change it,
>it should be done via a slow deprecation rather than by fiat.
>As before, I'm -1 to moving code from commons.collections.primitives into
>the sandbox, since:
>(a) The code is well within the scope of commons-collections, so demoting
>it for the sole purpose of removing it from commons-collections seems
>questionable at best.
>(b) The code is well over a year old, stable, 100% tested, and well used
>in production environments (including two generations of commercial,
>off-the-shelf products), and other open source projects (including some
>here in commons) use or have expressed an interest in using these classes.
>Moving this stuff further away from a formal release is a disservice to
>those users.
>(c) Adding the primitive collections to the commons-collections code base
>is an old decision that was openly discussed on this list.  Indeed, you
>yourself expressed approval for this action
>as did a total of 4 committers (with no dissenters).
>(d) When viewed through a common-use or common-cause-for-change metric,
>the primitive collections and the collections packages have very high
>cohesion.  Indeed, they have higher cohesion on the latter point than most
>arbitrary pairs of types in commons-collections.
>sc> This actually works well, as I want to try implementing [primitives]
>sc> as direct implementations of List, Collection, Map et al. - no
>sc> separate adaptors. So, there is a good case for the separation.
>As you are well aware, we've played with this approach in the past and
>found it wanting.  Among other drawbacks, you lose the ability to use the
>primitive collections independent of the java.util Collections (for
>example on many micro and J2ME platforms).  Perhaps more importantly, the
>pollution of the namespace becomes significant, a point that you and
>others have noted in the past:
>(On this note, your preferences on the "design decisions" thread seem
>inconsistent on this point.  You state a preference for extending the
>Collections interfaces (e.g., "IntCollection extends Collection"), but you
>also state a preference for not "following the Sun Framework closely".)
>Having authored and extensively worked with the code both ways, personally
>I strongly prefer the adapter approach utilizing small, focused,
>composable pieces.
>sc> How does this sound???
>As before, I'm open to (a) leaving the primitive collections where they
>are, (b) splitting the distribution of commons-collections into primitive
>and object based implementations or (c) proposing a new commons proper
>component, dependent upon commons-collections, containing the primitive
>collections and possibly more.  Note that to do (c) will require
>re-implementing, copying, refactoring or releasing the commons-collections
>test framework.
>Specifically, I'm not strictly opposed to introducing a [primitives] or
>[pcollections] component that contains what's currently
>org.apache.commons.collections.primitives.* and whatever else seems to fit
>well.  (Although I'm not confident that's a good idea either.)  I am
>opposed to moving code from commons proper to the sandbox for that
> - Rod <>
>sc> Stephen
>To unsubscribe, e-mail:
>For additional commands, e-mail:

View raw message