commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [collections] deprecate CursorableLinkedList?
Date Thu, 18 Sep 2003 21:07:37 GMT
On Thu, 18 Sep 2003, Rodney Waldhoff wrote:

> Date: Thu, 18 Sep 2003 10:03:54 -0700 (PDT)
> From: Rodney Waldhoff <>
> Reply-To: Jakarta Commons Developers List <>
> To:
> 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 <>

Craig McClanahan

View raw message