commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [collections] jar file names
Date Wed, 01 Oct 2003 22:33:07 GMT
From: "Rodney Waldhoff" <>
> > Of course, my view remains that primitives are a
> > specialised extension to collections, not part of
> > the main code. As you know, I don't believe that
> > they should be directly managed with [collections].
> > For example, I was going to invite you to write
> > the release notes for primitvies, as you are
> > the only coder in those packages.
> Don't do anything you're not comfortable with, but frankly I'm beginning
> to resent repeated attempts to ghettoize this code base.  The primitive
> collections have just as many committers, and quite likely more users, as
> other collections sub-packages (notably collections.observed.*). They are
> designed around real-world user experience. They have 100% test coverage.
> They have been stable for nearly 9 months.
I want to be clear that I have no problems with the quality, stability or
user-base of this code. Good code should be released and used.

I see this as independence, rather than ghettoization, and I believe it to
be in the best interests of both areas of code.

My regret is that I did not fully consider the implications of including the
primitive packages in collections at the outset. Simply counting java files
shows that the primitives packages are now about 50% of [collections]. And
there are no Map implementations yet, or decorators other than a few
unmodifiable ones.

In addition the release notes factor weighs on my mind. The document
describing the release will be very large just with objects, and naturally
breaks into two.

> Just because you personally
> aren't interested in using this code (or more accurately, just because
> you're interested in exploring alternative implementations of this code)
> doesn't justify ostracizing it from the rest of the package.  You're
> trying to make the primitive collections a second-class citizen here.
Although I can understand how this appears, I was uncomfortable with the
primitives code in [collections] before starting the sandbox primitives.
Clearly I should have raised my concerns earlier.

> As before, if you want to make primitive collections a first class citizen
> in another commons proper component, then propose that, but it will
> require some extra work to extract the shared bits from the
> commons-collections code base.
OK I'll make a proposal:
1) We create a new commons-proper component pcollections? to maintain
primitive collections.
2) Code is copied into pcollections, renaming the package. (or maybe it
could keep the same package?)
3) The code in collections is deprecated, with a snapshot jar being made so
backwards compatability works.
4) [collections] produces a commons-collections-tests.jar file to enable the
tests to work. This contains only the abstract test class framework from
I am willing to do most of the work.

PS. The ant script should be reverted now.

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

View raw message