On Thu, 18 Sep 2003, Rodney Waldhoff wrote: > Date: Thu, 18 Sep 2003 10:03:54 -0700 (PDT) > From: Rodney Waldhoff <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [collections] deprecate CursorableLinkedList? > > 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. >
I'm a happy user of CursorableLinkedList in a couple of scenarios where you want to process a series of events, and the event handlers can insert or remove events from the queue while you're iterating. It's quite handy, so this is a nonbinding -1 on deprecating/removing it. I have no problem with removing "implements Serializable" though, because I do not rely on being able to persist instances. > - Rod <http://radio.weblogs.com/0122027/> > Craig McClanahan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
