+1 to Seb's observations http://people.apache.org/~simonetripodi/ http://www.99soft.org/
On Fri, May 6, 2011 at 1:57 PM, sebb <seb...@gmail.com> wrote: > On 6 May 2011 12:26, Jochen Wiedmann <jochen.wiedm...@gmail.com> wrote: >> +1 for Java 1.6 >> >> Java 1.6 is now 5 years old, Java 1.5 is officially obsolete, or even >> deprecated by Sun/Oracle and we should try to keep things simple. >> > > Not all OSes are supported by Sun/Oracle, and not all JVM vendors > update their products as quickly. > > There may still be OSes that don't support Java 1.6 yet. > > I know that OpenVMS tends to lag behind, but they do have Java 1.6 for > I64 hardware. > However they don't have 1.6 for Alpha hardware which AFAIK is still > very much in use. > > I don't know about IBM OSes - does anyone know about their Java support? > > Even when new versions of Java are available, many companies take a > long time to update their systems. > > Also, won't requiring 1.6 for Pool force DBCP to use 1.6 also? > > I'm not saying that we should not use 1.6, but I think we should > strive to make pool compatible with 1.5 if at all possible. > >> >> On Fri, May 6, 2011 at 12:43 PM, Mark Thomas <ma...@apache.org> 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 currently 1.5. >>> >>> It would make the implementation of the FIFO/LIFO allocation option >>> considerably easier if that was changed to 1.6. >>> >>> 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 >>> >>> 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). >>> >>> Mark >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> >> >> -- >> I Am What I Am And That's All What I Yam (Popeye) >> >> --------------------------------------------------------------------- >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
