On Tue, 2006-02-14 at 21:47 -0500, Sandy McArthur wrote: > A lot of this was brought up in Nov 2005 starting with Robert's post: > http://tinyurl.com/aq7cx
feel free to add this road map to the wiki ;) > Now that all known issues for the existing Pool code have been fixed > I'd like to see one more release of the current code base, probably > dubbed 'Pool 1.3'. I also think this should be announced as the last > version of Pool that will support Java 1.3 JVMs. There really are some > big bugs that were fixed and this should be a drop in replacement for > anyone using the current version pool. +1 i would prefer a positive announcement about 2.0's requirements. there is no reason why a 1.3.1 release couldn't be cut if there is a good enough reason. i see no reason to exclude a backport to 1.3 of the 2.0 codebase so long as new developers are willing step up for this task. it's just that the main code stream that will now be targeted at more modern JVMs only. i should some more free time now that the JCL release work is mainly done. there are some issues to be resolved to do with cutting mavenized releases i'll try to find time to look into them. > After that I'd like to see the prep towards 'Pool 2.0' started. In > addition to seeing my composite pool implementation added I'd like to > start the process to cleaning up the API as I described back in > November: http://tinyurl.com/76f4n If I recall correctly those changes > don't break API compatibility, only change the behavior to be more > friendly to client code. +1 > The goals of 'Pool 2.0' would be: > * move Java 1.4 as a requirement (eg: the composite implementation > currently uses 1.4 features) > * tighten the behavior of the various implementations (eg: the when > and why of calls to PoolableObjectFactory.makeObject(), > .activateObject(), and .validateObject() aren't consistent.) > * Document the planed changes that will break API implementation > compatibility with the 'Pool 3.0' interfaces. (The changes I want > shouldn't break API compatibility with client code that transitions > from Pool 1.x to 3.0) > * released in the near future > > One example of a 2.0 change is changing ObjectPool.getNumActive() to > return a negative value instead throwing an > UnsupportedOperationException when that method isn't supported by the > pool implementation. (UnsupportedOperationException is a > RuntimeException so removing it from the interface doesn't break the > API) > > A change I'd like documented for 2.0 and planed for 3.0 is the more > aggressive changes like making it so ObjectPool interface for the > methods .close(), .clear(), .invalidateObject(), and .returnObject() > don't throw any Exceptions, currently they throw Exception. I think if > there is an Exception, not an Error, they should make a good effort to > clean up, discard the problem object the client is done using, and > fail silently. My thinking is that client code will be more interested > with being done with an object or shutting down than dealing with > problems with the pool. +1 > The goals of 'Pool 3.0' would be: > * implement the more aggressive API changes announced with 2.0. > * require Java 1.5 > ** use the new util.concurrent for better multi-threaded performance > ** consider generic support > ** add JMX monitoring +1 > * to be released sometime in 2007, maybe might be better not to set an official date: sometimes unexpected things happen :) - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
