commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: [pool] [POOL-208] Support Java 1.5 Generics in version 1.x.
Date Sun, 25 Dec 2011 23:50:54 GMT

-----Original Message----- 
From: Konstantin Kolinko
Sent: Sunday, December 25, 2011 1:15 AM
To: Commons Developers List
Subject: Re: [pool] [POOL-208] Support Java 1.5 Generics in version 1.x.

2011/12/23 Christian Grobmeier <>:
> On Wed, Dec 21, 2011 at 7:31 PM, Phil Steitz <> 
> wrote:
>> On 12/21/11 11:09 AM, Gary Gregory wrote:
>>> On Wed, Dec 21, 2011 at 1:03 PM, Mark Thomas <> wrote:
>>>> On 21/12/2011 16:57, Phil Steitz wrote:
>>>>> On 12/21/11 9:41 AM, Christian Grobmeier wrote:
>>>>>> On Wed, Dec 21, 2011 at 5:19 PM, Phil Steitz <>
>>>> wrote:
>>>>>>> 1.5.x ships with tomcat and is used by lots of other production
>>>>>>> applications.  We need to maintain the ability to patch it.
>>>>>> Tomcat 5.5 (the oldest stable version i can find) uses Java 5:
>>>>>> This proposed release is binary compatible - they should not have
>>>>>> issue to upgrade, right?
>>>>>> How long would you like to maintain the elder 1.5.x code without
>>>>>> 5
>>>> support?
>>>>> At least until 2.0 is out and for some time after that.  Asking
>>>>> tomcat and others to upgrade twice makes no sense.  I will let Mark
>>>>> or other tc committers comment on that.
>>>> Tomcat will continue to use 1.5.x since that is what DBCP uses. When
>>>> 2.0.x is ready, trunk will switch to 2.0.x and the associated DBCP
>>>> release. Depending on the results, the release branches (5.5.x, 6.0.x
>>>> and 7.0.x) may follow.
>>>> Tomcat is highly unlikely to use Pool 1.6.x
>>> Which is quite fine with me.
>>> My goal is only to provide a version of pool-1 with generics that is as
>>> least disruptive as possible.
>> That is great for your own use, but what releasing it does is sets
>> us up to support 3 versions.  We are having a hard enough time just
>> supporting one.  When we release 2.0, we will have two release
>> branches to maintain.  The 1.5.x code itself is fairly stable, but
>> 1.5 was pretty much a complete rewrite of the core code and I expect
>> we will continue to get bug reports against this code.  Maintaining
>> two versions of it does not sound fun to me and I really think it is
>> unwise to set ourselves up to try to do it.
> OK, sorry if I ask the same question in the same dumb way all the
> time... but we have figured out 1.5 will be binary compatible with
> 1.6.
> We can't we then simply drop 1.5 and go forward with 1.6?
> So far i have see the reason: Tomcat 5.5 runs with jdk1.4.2. Is this
> actually the reason we don't go forward? Because another project needs
> the 1.5 series?
> If this is the case, then the EOL of Tomcat 5.5 is the earliest EOL of 
> Pool 1.5.
>I think Tomcat 5.5 can go with latest released version of pool 1.5,
>taking it from archives.
>TC 5.5 is currently configured to use pool 1.5.5 (as opposed to later
>1.5.6 or 1.5.7) [1], and I am not going to propose upgrade of that,
>though other Tomcat committers can propose it.
>The only question might be if there are some critical bug fixes (and I
>think you will be able to backport those).
>Also I wonder what changes are required in Gump configuration.

There isn't any change needed for Gump since TC 5.5 doesn't run tests there 
and doesn't have a compile time dependency on [pool].

> This does mean pool can earliest go forward in September 2012:
> Just want to know. I ask this because I start to believe we should
> introduce EOL dates for our components.
> On 1.6, question is if this series will be so time consuming as
> expected. After all, 1.5 dev is at a minimum as understood it. It
> should be easy for Gary to move the changes to 1.6 version, if he is
> willing to care on that (nasty tongues tell me Git would help in this
> case).
> If 1.6 is coming and this project does not support it, how can we
> handle it? After all we are not working for the Tomcat project, we are
> working for ourselves, and Gary needs a generic version. I would not
> like to see him going and make up a github fork. People outside of
> this project are already saying we are like dinosaurs (collections vs
> guava). We should probably discuss how we can do this - probably Gary
> could make some kind of "half official" release, a bit of an
> "experimental" tagged one. One people do not rely upon, except they
> know what they are doing. Probably a 1.5-extended version, like in
> Lord of the Rings.

Best regards,
Konstantin Kolinko

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

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

View raw message