Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 18324 invoked from network); 19 Feb 2002 20:27:16 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 19 Feb 2002 20:27:16 -0000 Received: (qmail 15278 invoked by uid 97); 19 Feb 2002 20:27:19 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 15262 invoked by uid 97); 19 Feb 2002 20:27:18 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 15250 invoked from network); 19 Feb 2002 20:27:18 -0000 Date: Tue, 19 Feb 2002 14:27:09 -0600 (CST) From: "Michael A. Smith" X-X-Sender: iammichael@champion.sslsecure.com To: Jakarta Commons Developers List , Morgan Delagrange Subject: Re: Collections 2.0? (Collections 1.1 RIP) In-Reply-To: <009501c1b980$429de100$8905050a@eb.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 them. 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 release. > > 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: http://jakarta.apache.org/commons/collections.html I suppose it wasn't explicitly stated though. But I agree here. Collections should be based on the 1.2 Collection APIs. regards, michael -- To unsubscribe, e-mail: For additional commands, e-mail: