On Fri, Jun 19, 2009 at 9:06 AM, Phil Steitz <phil.ste...@gmail.com> wrote:
> 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. > I will supported 3), Reason being there are totally new data structures in java.util.concurrent.*, which should be heart of new implementations. We should also try to keep interfaces similar to Pool 1.X track. -Dheeraj > > Phil > > Mark >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
