commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
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

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


Mime
View raw message