Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 32429 invoked from network); 19 Aug 2002 18:29:27 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 19 Aug 2002 18:29:27 -0000 Received: (qmail 5027 invoked by uid 97); 19 Aug 2002 18:29:56 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 4991 invoked by uid 97); 19 Aug 2002 18:29:55 -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 4979 invoked by uid 98); 19 Aug 2002 18:29:54 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: From: "Jack, Paul" To: 'Jakarta Commons Developers List' Subject: RE: [Collections] Release potential? Date: Mon, 19 Aug 2002 11:28:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > I'm sorry to bring these things up at a rather late date > but I guess it's better now than after the release. Well, yes and no. Things that can't be changed after the release should be addressed now. Things that can be added later should be, IMO, because there are people seriously waiting on a new Collections release, and I wouldn't want to rush new features. In your list here, #2 must be addressed immediately. #1 can be without hurting anything, so if you've got the patches, by all means submit them. But #3 would require much thought as to what goes into the interface (can't add new methods later) so I'd prefer to defer it until after the release. The existing classes can always implement a new interface without breaking backwards compatibility. Regarding #2, I'm not sure I agree with you. Whereas yes, the term "ArrayList" implies that it subclasses ArrayList, the JavaDoc clearly indicates that it doesn't, and I'm not sure what a better name would be for a list backed by an int array. Did you have something else in mind? -Paul > > 1) It would be nice to have better class documentation on > the "primitive" package classes. It is unobvious to me > (looking at the API) what using IntArrayList would "buy" me > other than no ClassCastExceptions. Is it faster or does it > use less memory or something else or neither? The API > should be obvious without having to look at the code. > > 2) ArrayList is a specific implementation that should not > be used in the name of these classes (AbstractIntArrayList > and IntArrayList) because it implies a certain > implementation (namely the use of ArrayList or subclass of > it) that isn't the case. The differences (ArrayList of > Integers vs. arrays of ints) are very important in terms of > memory usage (see > http://www.javaworld.com/javaworld/javatips/jw-javatip130.html). > > 3) I would greatly prefer to have an IntList interface so I > can declare variables and arguments with an interface > instead of an abstract super class (like we do with the > collection interfaces). See Joshua Bloch's "Effective > Java" item number 16 on page 84. He agrees with me too. > > Does anyone else see this the way I do? I'd be happy to > commit documentation improvements (#1), but I don't think I > am known enough to get approved. (I wrote the > TransformingComparator class which I think IMHO is pretty > well documented). > > Jonathan > > > --- "Jack, Paul" wrote: > > > I'm a big fan of having the release notes completed > > prior to > > > a release. The release vote then is a simple "these > > exact > > > bits are what we are releasing" rather than some > > unknown product... > > > > Ok, I'll work on the release notes then. > > > > > > > It seems like everything has been addressed, but I'd > > like to take a > > > closer look over my todo list. Unfortunately, I won't > > have > > > time until at least Saturday. > > > > Ok. > > > > > > > Does this also mean you're volunteering to be the > > release manager for > > > the release? :) > > > > I guess so. Why not bring my compulsive obsessions with > > the Collections > > API to their natural end... > > > > -Paul > > > > > > -- > > To unsubscribe, e-mail: > > > > For additional commands, e-mail: > > > > > > > > ===== > Jonathan Carlson > joncrlsn@users.sf.net > Minneapolis, Minnesota > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > > -- > To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: