Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4762E140.3050805@oliver-heger.de>
Date: Fri, 14 Dec 2007 21:02:08 +0100
From: Oliver Heger <oliver.heger@oliver-heger.de>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Jakarta Commons Developers List <dev@commons.apache.org>
Subject: Re: [configuration] JDK compatibility
References: <4760DC4B.5010101@oliver-heger.de>
 <F0D7281DAB048B438E8F5EC4ECEFBDDC027A2A00@esmail.elsag.de>
In-Reply-To: <F0D7281DAB048B438E8F5EC4ECEFBDDC027A2A00@esmail.elsag.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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.
> 
> Just my 2 cents,
> J�rg
> 
This is pretty much the reaction I was hoping for :-)

So I will probably follow this road. This is a good opportunity for a 
refactoring and polishing of some interfaces and base classes. Because 
we will have major changes, changing the package name (maybe to 
o.a.c.configuration2?) will certainly make sense.

It would be good however to handle this commons-wide in a consistent way.

Oliver

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