commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [POOL2] Java 1.5 or 1.6?
Date Fri, 06 May 2011 12:24:07 GMT
+1 to Seb's observations

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Fri, May 6, 2011 at 1:57 PM, sebb <sebbaz@gmail.com> wrote:
> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message