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 <[EMAIL PROTECTED]> wrote: > > Actually, commons pool already depends upon commons collections, so it's not > > that much of a stretch. > > On 11/9/05, James Carman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
