Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Thu, 18 Sep 2003 14:07:37 -0700 (PDT)
From: "Craig R. McClanahan" <craigmcc@apache.org>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [collections] deprecate CursorableLinkedList?
In-Reply-To: <20030918095208.R99940@minotaur.apache.org>
Message-ID: <20030918140525.U20074@minotaur.apache.org>
References: <20030918095208.R99940@minotaur.apache.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 18 Sep 2003, Rodney Waldhoff wrote:

> Date: Thu, 18 Sep 2003 10:03:54 -0700 (PDT)
> From: Rodney Waldhoff <rwaldhoff@apache.org>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: commons-dev@jakarta.apache.org
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org