commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [POOL2] Java 1.5 or 1.6?
Date Fri, 06 May 2011 11:57:55 GMT
On 6 May 2011 12:26, Jochen Wiedmann <jochen.wiedmann@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 <markt@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> ---------------------------------------------------------------------
> 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