commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [POOL2] Java 1.5 or 1.6?
Date Fri, 06 May 2011 15:24:35 GMT
On 5/6/11 3:43 AM, Mark Thomas wrote:
> Before I go too far down the road of the re-writing the core object
> allocation code for pool2, I'd like to get some clarity on what the
> minimum Java version targeted by pool2 should be.

It is also logical to ask at this point if the rewrite is desirable
/ necessary and what we expect to gain from it.  I have pretty
consistently advocated this, but given the work and inevitable
stabilization required, we should at least ask the question.  Seems
to me the goals should be 0) performance 1) maintainability 2)
robustness 3) (configurable?) fairness.  Do you agree with these and
are you sure the rewrite is necessary to get them?

> It is currently 1.5.
> It would make the implementation of the FIFO/LIFO allocation option
> considerably easier if that was changed to 1.6.

Can you explain a little what the problem is?
> The options as I see them are:
> a) Java 1.5 with FIFO or LIFO allocation
> b) Java 1.5 with FIFO allocation only
> c) Java 1.6 with FIFO or LIFO allocation
> b) & c) are likely to be considerably easier to write since I can use
> the classes provided by java.u.c
> a) looks like it will be a PITA to write
> My preferred option is c)
> I think b) is a bad idea since it makes idle object expiration harder

Right, if there is only one option it should be LIFO (as it was in
pool 1.0-1.2).  I think configurability is good.

> I think a) is a bad idea as I don't want to have to figure out how to
> make that work, not do I want to have to maintain it once it is written
> as I suspect it will end up being quite complex (although I could be wrong).

I share sebb's concerns that this is going to leave some users
behind, but they will still have 1.x and it seems a fair expectation
that to get the new version they need to 1.6.   This is consistent
with what we are doing in DBCP.    So once I understand what the
problem is, I will end up +1 on option c).

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

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

View raw message