commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [configuration] JDK compatibility
Date Thu, 13 Dec 2007 09:32:13 GMT

On 13.12.2007, at 09:42, Jörg Schaible wrote:

> Oliver Heger wrote:
>> (There was a similar discussion about commons lang recently.)
>> Configuration used to support JDK 1.3. For the next release (either
>> 1.6 or 2.0) I would like to drop this compatibility. The number
>> of feature
>> requests that require a newer JDK version is increasing.
>> This raises a couple of questions:
>> - To which JDK version should we switch? 1.4 or immediately to 1.5?
>> - Should creating a compatibility branch be considered? (I doubt that
>> there is enough energy and motivation for maintaining
>> multiple branches.)
>> - Does a switch in the JDK version require a major release?
>> - Is a new package name required (at least for a major
>> release if there
>> are binary incompatible changes)?
>> Any thoughts?
> - go for 1.5
> - take advantage of generics
> - make 2.x
> - use a different package name to allow 1.x and 2.x series to co-exist
> - put 1.x branch into maintenance mode
> - take this as chance to refactor and drop/clean-up any legacy  
> stuff (setDelimiter, setThrowExceptionMissing)
> IMHO a lot of the current Commons components lack of activity and  
> contributors, since everytime someone comes along and provides  
> patches or requests feature support based on stuff available in  
> newer JDKs (e.g. Preferences for commons-configuration), it is  
> turned down by the "have to be compatible to JDK 1.1" argument.  
> While keeping compatibility is basically a good thing and  
> necessary, we should not hesitate and move on at some time. The new  
> language features of Java 5 are a good reason to do so.
> However, the old versions do not suddenly vanish also. It's just,  
> that they don't get new features. If someone is really eager on  
> porting a new feature of the head revision into the 1.x branch and  
> make a release ... it's not forbidden.

+1!!! Frankly speaking this is probably applies to most of commons.

If commons wants to stay relevant and not become just legacy we also  
need to take some steps forward.

/me points to Google collections

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

View raw message