commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michiel Kalkman" <>
Subject Re: [configuration] JDK compatibility
Date Thu, 13 Dec 2007 16:52:58 GMT
On 12/13/07, Torsten Curdt <> 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

> > - 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:
> For additional commands, e-mail:

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

View raw message