commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Smith" <>
Subject Re: Collections 2.0? (Collections 1.1 RIP)
Date Tue, 19 Feb 2002 20:27:09 GMT
On Tue, 19 Feb 2002, Morgan Delagrange wrote:
> > Is there a whole list of 'things that ought to be done' we could compile
> > for Collections? Then target 2.0 with an aim to clear those up?
> +1.  I'm willing to track (informally) that kind of information.

I read that question as "is there an existing list" and I believe the 
answer to that question is:  no, but Morgan is proposing to create and 
manage that list so that we can push towards a 2.0 release.

> > Hell, Collections is pretty small, we could go through it a component at a
> > time and solicit opinions, then solve and tick off, then declare 2.0?
> If you want.  That sounds like overkill to me.  No need to go looking for
> work to do, I'd prefer to let folks just scratch their itches.

That's kind of what I started with my patches.  Call it my itch.  I'm
bored, and looking for a project to keep me busy at home.  So I started 
going through each collections class, peer-review style.

However, I think the key here though is not reviewing the components that
already exist, but what else should we add.  That is, what other types of
collections should we be including in a Collections 2.0 release?  Part of
that answer is figuring out what exists in other jakarta projects that
could be pulled into commons so that other jakarta projects can reuse

Someone recently brought up comparators.  That would probably be a good
addition.  There's probably others as well -- haven't seen a splay-tree
implementation yet, but does anyone actually use them?  :)

> > Is there a list of changes from 1.0 that are being made to 2.0?
> Please send any changes of note to the list.  Here's what I know of:
>  - New collection: SynchronizedHashMap
>  - Reimplementation and bug fixes to LRUMap (probably)
>  - LRUMap can no longer be cast to a HashMap (probably)
> I also know of some other new classes, like the Bag classes, but I would
> prefer the contributors to send a short note on their purpose and status,
> rather than having one of the uninitiated comb through the CVS logs.

Doesn't seem like much of an addition to call it a 2.0 release, but I 
suppose that's what's required because of the incompatibilities. :)  Maybe 
we'll find some more collection code that can be added before a 2.0 

> > Should 2.0
> > enforce a Java 1.2 usage?
> Not sure I follow here.  Maybe you mean something like, "Should we note in
> our docs that any class in Collections may rely on Java 2 Collections in
> future releases?"  If so, then definitely yes, let's include that in the
> contract for the product.

I thought that was implied by the intro to the collections component:

I suppose it wasn't explicitly stated though.  But I agree here.  
Collections should be based on the 1.2 Collection APIs.


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

View raw message