commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
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
>>> http://wiki.apache.org/jakarta-commons/PoolRoadMap (last edited
>>> 2006-09-10 02:28:23 by SandyMcArthur). Other than that, bug related to
>>> this at http://issues.apache.org/jira/browse/POOL-83. 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
>
> https://svn.apache.org/repos/asf/commons/proper/pool/branches/2_0_DEV/
>
> ?
>
> 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.

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


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


Mime
View raw message