commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: Pool: comments requested for a new implementation
Date Thu, 10 Nov 2005 22:23:00 GMT
On Wed, 2005-11-09 at 13:43 -0500, Sandy McArthur wrote:
> Currently Pool only depends on the CursorableLinkedList when using the
> Generic[Keyed]ObjectPool classes. I'd like to see this go away for two
> reasons.
> First, because the size of the Collections jar (546K) dwarfs the Pool
> jar (41K) and it's a slightly more of a hassle to manage two libs vs
> one.
> Second, because the advantage of a CursorableLinkedList has a
> Cursor/ListIterator that allows concurrent modification to the list
> while using the cursor. Pool's use of this cursor is synchronized so
> that while the cursor is being used no other access to the object pool
> is allowed, negating the advantage of the CursorableLinkedList.

+1

libraries are not only more useful and user friendly with minimal core
dependencies but also a lot of compatibility pain is saved in the long
run. bricks are best :)

> On 11/9/05, James Carman <james@carmanconsulting.com> wrote:
> > Actually, commons pool already depends upon commons collections, so it's not
> > that much of a stretch.
> 
> On 11/9/05, James Carman <james@carmanconsulting.com> wrote:
> > If you don't mind a dependence upon Commons Collections, you should come up
> > with a BufferPool, using the Commons Collections Buffer interface.  The
> > Buffer interface allows you to abstract away the LIFO vs. FIFO vs. priority
> > queue vs. some other implementation stuff.  All you do is call remove() and
> > add().  That way, if you wanted a new type of pool, you just supply a
> > different implementation of Buffer.  Just an idea! :-)

IMHO there isn't any reason why an optional module with a dependency
upon collections couldn't be added to pool.

not sure i see the use cases properly right now but then again it's not
my itch. james: if you fancy coding it up, that'd be cool. if you like,
park it in a friendly branch so we can all take a look :) 

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message