Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 9769 invoked from network); 18 Sep 2003 17:04:01 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 18 Sep 2003 17:04:01 -0000 Received: (qmail 79199 invoked by uid 500); 18 Sep 2003 17:03:48 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 79114 invoked by uid 500); 18 Sep 2003 17:03:47 -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 79101 invoked from network); 18 Sep 2003 17:03:47 -0000 Received: from unknown (HELO minotaur.apache.org) (209.237.227.194) by daedalus.apache.org with SMTP; 18 Sep 2003 17:03:47 -0000 Received: (qmail 9727 invoked by uid 1304); 18 Sep 2003 17:03:54 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Sep 2003 17:03:54 -0000 Date: Thu, 18 Sep 2003 10:03:54 -0700 (PDT) From: Rodney Waldhoff To: commons-dev@jakarta.apache.org Subject: [collections] deprecate CursorableLinkedList? Message-ID: <20030918095208.R99940@minotaur.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N If there are no complaints, I'd like to deprecate CursorableLinkedList for the 3.0 collections release, to be removed in the 4.0 release. CursorableLinkedList provides a List implementation that supports a type of Iterator (called a Cursor) that isn't bothered by concurrent modifications--you can safely add or remove items before or after the current location of the cursor and the cursor will simply see the current status of the list when it gets there. While this functionality works fine, it's too complicated by half, and there are bugs in other areas of the interface (well, the only bug I'm aware of is that it isn't really Serializable, despite what the interface claims.) I suspect that commons-pool is the only consumer of this class, where it is used to walk through the set of pooled objects while borrowObject or returnObjct calls may asynchronously modify the underlying list. By deprecating (and eventually removing) this class, we could either move CursorableLinkedList over to pool, or (my preference) replace the CursorableLinkedList with a significantly simpler but slightly less predictable approach (like iterating via list.get(counter++%list.size()), but that's a topic for another thread. Contrariwise, if we'd like to keep CursorableLinkedList, we should either fix the Serialization or remove the "implements Serializable" part of the class declaration. - Rod --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org