A lot of this was brought up in Nov 2005 starting with Robert's post: http://tinyurl.com/aq7cx
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. 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. 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. 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 * to be released sometime in 2007, maybe -- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
