You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Oliver Heger <ol...@oliver-heger.de> on 2007/12/13 08:16:27 UTC
[configuration] JDK compatibility
(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?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] JDK compatibility
Posted by Emmanuel Bourg <eb...@apache.org>.
Hi all,
I'm a bit late in this discussion, I'm quite favorable to an upgrade of
the minimum JDK required, JDK 1.3 compatibility is really handicapping
nowadays. I just hope this doesn't imply designing a new configuration
API based on the current code, or this could turn into another cli2 like
never finished project.
Regarding the new package name, I prefer org.apache.commons.config
rather than org.apache.commons.configuration2. It's shorter, still
meaningful and version independent (I hope we'll not need another
package change anytime soon!).
Emmanuel Bourg
Oliver Heger a écrit :
> (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?
>
> Oliver
>
> ---------------------------------------------------------------------
> 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
Re: [configuration] JDK compatibility
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Oliver Heger skrev den 13-12-2007 08:16:
> - Does a switch in the JDK version require a major release?
>
Please keep any changes in environmental requirements to a major
release. I for one expect that 1.Y may replace 1.X without any thought.
--
Thorbjørn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] JDK compatibility
Posted by James Carman <ja...@carmanconsulting.com>.
Yes, the configuration2-packaged classes should be part of the 2.x
release series.
On 12/18/07, Torsten Curdt <tc...@apache.org> wrote:
> >> 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.
> >
> > I'd go for o.a.c.configuration2 here.
>
> same here
>
> >> It would be good however to handle this commons-wide in a
> >> consistent way.
> >
> > The question is: Should we start again with 1.0 for such a
> > component or do we align the number in the package with the major
> > number if we expect a completely incompatible package?
> >
> > Example for a version histories:
> >
> > - with aligned major number:
> >
> > o.a.c.configuration: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5
> > o.a.c.configuration2: 2.0, 2.1, 3.0, 3.1, 3.2, 4.0
> > o.a.c.configuration5: 5.0, 5.1
>
> IMO the above is more straight forward than the following...
>
> > - with resetted number:
> >
> > o.a.c.configuration: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5
> > o.a.c.configuration2: 1.0, 1.1, 2.0, 2.1, 2.2, 3.0
> > o.a.c.configuration3: 1.0, 1.1
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> 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
Re: [configuration] JDK compatibility
Posted by Torsten Curdt <tc...@apache.org>.
>> 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.
>
> I'd go for o.a.c.configuration2 here.
same here
>> It would be good however to handle this commons-wide in a
>> consistent way.
>
> The question is: Should we start again with 1.0 for such a
> component or do we align the number in the package with the major
> number if we expect a completely incompatible package?
>
> Example for a version histories:
>
> - with aligned major number:
>
> o.a.c.configuration: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5
> o.a.c.configuration2: 2.0, 2.1, 3.0, 3.1, 3.2, 4.0
> o.a.c.configuration5: 5.0, 5.1
IMO the above is more straight forward than the following...
> - with resetted number:
>
> o.a.c.configuration: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5
> o.a.c.configuration2: 1.0, 1.1, 2.0, 2.1, 2.2, 3.0
> o.a.c.configuration3: 1.0, 1.1
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [configuration] JDK compatibility
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Hi Oliver,
[snip]
Oliver Heger wrote:
> 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.
I'd go for o.a.c.configuration2 here.
> It would be good however to handle this commons-wide in a
> consistent way.
The question is: Should we start again with 1.0 for such a component or do we align the number in the package with the major number if we expect a completely incompatible package?
Example for a version histories:
- with aligned major number:
o.a.c.configuration: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5
o.a.c.configuration2: 2.0, 2.1, 3.0, 3.1, 3.2, 4.0
o.a.c.configuration5: 5.0, 5.1
- with resetted number:
o.a.c.configuration: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5
o.a.c.configuration2: 1.0, 1.1, 2.0, 2.1, 2.2, 3.0
o.a.c.configuration3: 1.0, 1.1
??
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] JDK compatibility
Posted by Oliver Heger <ol...@oliver-heger.de>.
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
Re: [configuration] JDK compatibility
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 13, 2007 8:42 AM, Jörg Schaible
<Jo...@elsag-solutions.com> 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 to what Jörg and Torsten said.
On the "use a different package name" issue I think there are
differing opinions and so probably will have to be decided on a
component-by-component basis by the devs involved in each component.
In general I'm OK with an incompatible change as long as we use a
major version number, but I think for other people/components wil opt
for changing the package name.
Niall
> Just my 2 cents,
> Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] JDK compatibility
Posted by Michiel Kalkman <mi...@gmail.com>.
On 12/13/07, Torsten Curdt <tc...@apache.org> wrote:
>
> On 13.12.2007, at 14:38, Michiel Kalkman wrote:
>
> > +1/-1
> >
> > I am all for using jdk 1.5, but I guess it will take some time before
> > I can use this jdk at work. Is it possible and easy to generate an 1.4
> > compatible binary version from 1.5 sources ? If so, I'd say go for it.
>
> This comes up all the time. Frankly speaking IMO this is a moo point.
> No one forces people to upgrade to a new version. Fact is though if
> you want the newer features you might have to bite the bullet and
> either upgrade your system or backport changes. The old stable
> version is just in maintenance mode and will not go away. But I am
> quite tired of having this backwards compatibility reasons making
> life at commons so much harder. Time moves on so should we. Of course
> it would be nice to provide binaries via retrotranslator ...if
> possible. But I think we need to move forward on this.
Points taken. I prefer going to jdk 1.5, I just think a number of
companies will not be able to follow soon. Furthermore, if there is a
possibility to make stuff backwards compatible, there is no reason for
a maintenance release.
>
> > Just some additional thoughts (maybe they should be in another
> > thread):
> > - when considering package names, maybe it is an idea to work towards
> > a plugin-alike structuring. It might be interesting if future
> > development of some configuration format (INI,JNDI,etc) could be
> > independent from, say, core components.
>
> Not sure what you mean here.
There is a lot of stuff in org.apache.commons.configuration and if you
want to reconfigure packages, at least consider something like
org.apache.commons.configuration.sources.* with code dealing with
specific formats like XML files or INI files in order to seperate them
from base classes, like BaseConfiguration.
A basic idea behind CommonsConfig is to separate configuration
processing from configuration formats, is it not ? I guess that should
be represented in the package structure.
I was also thinking of something like OSGI. Just a small core.
Format-specific stuff in plugins, etc. Then just use the plugins you
need; if you need XML, include xerces, otherwise don't. Release new
plugins independent from the core. But that is probably too
farfetched.
>
> > - I think some prototype ui components (swing,jsp,etc.) might be a
> > useful future addition, if only as a starting point for developing
> > really useable ui components (and probably also as a teaser for new
> > users), so you might want to consider that when considering package
> > names as well.
>
> You mean as new projects? ...I think that's for some other thread :)
Well, if someone has a sample of using CommonsConfig in swing or jsp,
i am interested :)
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> 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
Re: [configuration] JDK compatibility
Posted by Torsten Curdt <tc...@apache.org>.
On 13.12.2007, at 14:38, Michiel Kalkman wrote:
> +1/-1
>
> I am all for using jdk 1.5, but I guess it will take some time before
> I can use this jdk at work. Is it possible and easy to generate an 1.4
> compatible binary version from 1.5 sources ? If so, I'd say go for it.
This comes up all the time. Frankly speaking IMO this is a moo point.
No one forces people to upgrade to a new version. Fact is though if
you want the newer features you might have to bite the bullet and
either upgrade your system or backport changes. The old stable
version is just in maintenance mode and will not go away. But I am
quite tired of having this backwards compatibility reasons making
life at commons so much harder. Time moves on so should we. Of course
it would be nice to provide binaries via retrotranslator ...if
possible. But I think we need to move forward on this.
> Just some additional thoughts (maybe they should be in another
> thread):
> - when considering package names, maybe it is an idea to work towards
> a plugin-alike structuring. It might be interesting if future
> development of some configuration format (INI,JNDI,etc) could be
> independent from, say, core components.
Not sure what you mean here.
> - I think some prototype ui components (swing,jsp,etc.) might be a
> useful future addition, if only as a starting point for developing
> really useable ui components (and probably also as a teaser for new
> users), so you might want to consider that when considering package
> names as well.
You mean as new projects? ...I think that's for some other thread :)
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] JDK compatibility
Posted by Michiel Kalkman <mi...@gmail.com>.
+1/-1
I am all for using jdk 1.5, but I guess it will take some time before
I can use this jdk at work. Is it possible and easy to generate an 1.4
compatible binary version from 1.5 sources ? If so, I'd say go for it.
Just some additional thoughts (maybe they should be in another thread):
- when considering package names, maybe it is an idea to work towards
a plugin-alike structuring. It might be interesting if future
development of some configuration format (INI,JNDI,etc) could be
independent from, say, core components.
- I think some prototype ui components (swing,jsp,etc.) might be a
useful future addition, if only as a starting point for developing
really useable ui components (and probably also as a teaser for new
users), so you might want to consider that when considering package
names as well.
(of course, I am a user, not a developer :)
On 12/13/07, James Carman <ja...@carmanconsulting.com> wrote:
> +1. We need to come up with a standardized way of dealing with this
> though I think. At first I didn't like changing package names, but it
> does help avoid the "jar hell" issue.
>
> On 12/13/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi!
> > >> - go for 1.5
> > >> - take advantage of generics
> > > +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.
> > +1 ... long overdue .... maybe too long!?
> >
> > Ciao,
> > Mario
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: [configuration] JDK compatibility
Posted by James Carman <ja...@carmanconsulting.com>.
+1. We need to come up with a standardized way of dealing with this
though I think. At first I didn't like changing package names, but it
does help avoid the "jar hell" issue.
On 12/13/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> >> - go for 1.5
> >> - take advantage of generics
> > +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.
> +1 ... long overdue .... maybe too long!?
>
> Ciao,
> Mario
>
>
> ---------------------------------------------------------------------
> 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
Re: [configuration] JDK compatibility
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
>> - go for 1.5
>> - take advantage of generics
> +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.
+1 ... long overdue .... maybe too long!?
Ciao,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] JDK compatibility
Posted by Torsten Curdt <tc...@apache.org>.
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
RE: [configuration] JDK compatibility
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org