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). 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
