commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [pool] Re: Apache Common Pool Road Map
Date Fri, 19 Jun 2009 03:36:54 GMT
Mark Thomas wrote:
> Phil Steitz wrote:
>> Dheeraj Kumar wrote:
>>> Hello,
>>> Congratulations on Pool 1.5.1 release.
>>> I was looking for Java 1.5 generics support on Apache Commons Pool and
>>> found out RoadMap at
>>> (last edited
>>> 2006-09-10 02:28:23 by SandyMcArthur). Other than that, bug related to
>>> this at I felt, it is
>>> good time to have another check on this RoadMap and combine release
>>> track for Pool  2.0 and Pool 3.0. As it will reduce lots of
>>> development/maintainance efforts. Anyone using JDK below 1.5, will be
>>> happy with 1.x track, and for JDK 1.5+ user, there will be Pool 2.x.
>> Thanks for the feedback.  The roadmap Wiki page definitely needs to be
>> updated.  I will do that following discussion here.  I agree with
>> combining the 2.0 and 3.0 tracks, but we need to agree first on what, if
>> any, behavior changes we implement as part of the next major release.  I
>> would also like us to continue supporting the 1.x branch for backward
>> compatibility and pre-JDK 1.5 environments.
>> At this point, other than addressing POOL-131,  I am not yet convinced
>> that we should implement any behavior changes beyond those that were
>> implemented in pool 1.4.   That is, of course, just my opinion and I am
>> open to suggestions on contract changes for 2.0.  Does anyone have
>> specific suggestions for API improvement or comments on the Wiki page?
> Generally, that list looks good.
> I'd agree we need to add POOL-131/logging. Obviously, that means picking a
> framework...
Yes.  Same applies to dbcp and if you look at the archives, the 
framework selection is where we have stalled in the past.  I would 
really like to get this fixed and while it is not really a pure "bugfix" 
would like to do something that could at least back port to a 1.x release.
> I'd also like to look at POOL-142. I understand the point that Sandy makes but
> it remains that not throwing the exception made writing test cases a lot harder.
>   Better logging is probably the way to handle this. Back to POOL-131 ;)
> My other question is what do we do about the code in
> ?
> With the recent changes for fairness and removing syncs, I suspect the code has
> diverged a lot.
The 2.0 branch was essentially a complete rewrite, so yes, it is 
"different."  I think we really have three alternatives for 2.0:

1) continue to build on the code in trunk, adding generics support but 
using the same core pooling / thread management code.
2) build on the code in the 2.0 branch
3) leverage JDK 1.5+ features to develop a new and simpler implementation

I think all are worth looking at.  I lean toward 1), because it makes 
backporting bugfixes easier, means we have less code to maintain, and it 
provides a lot of flexibility and good performance.  I have not thought 
that much about 3) and have not looked at 2) in quite a while.  The 
downside of 1) is that the code is not exactly "inviting."  We have had 
a hard time attracting and retaining a community around pool I think 
partly because of this.  The code is not that easy to follow and the 
fairness stuff actually makes it a little harder.  So if we do go that 
route, we should think about ways to continue to improve the documentation.

> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message