commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <>
Subject Re: [collections] jar file names
Date Wed, 01 Oct 2003 22:57:15 GMT
For what it's worth, I think your proposal may be the best idea.  The 
primitive collections would probably take up the bulk of the 
[primitives] project anyway, and may create some of the same issues in 
that code base as it has with [collections].

It appears that this situation involves a plan to deprecate something 
that hasn't been released yet.  This seems backwards to me.  No matter 
how stable or great the primitive collections have proven to be, they 
haven't been released, so I think it's of utmost importance to make the 
right decision here.  Releasing these classes only to deprecate them in 
a few months isn't any better for users then keeping them in the sandbox 
for a few months until they are promoted and released.   Actually, I 
think the latter is better.

Maybe a larger [vote] is required but I think that moving the primitive 
collections out will be better in the long run for everybody.  The 
benefit of releasing these classes as part of collections 3.0 isn't 
apparent to me.

Stephen Colebourne wrote:

> 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
> collections.
> I am willing to do most of the work.
> Stephen
> PS. The ant script should be reverted now.

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

View raw message