commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryce L Nordgren <>
Subject Re: [collections] VOTE: Collections-java5 direction ; notifying collections
Date Tue, 13 Mar 2007 18:00:12 GMT

Stephen Kestle <> wrote on 03/12/2007
09:15:11 PM:

> Bryce L Nordgren wrote:
> > Are you going to still produce binary releases which are compatible
> > 1.4, even though they won't be able to compile the new source releases?
> > are you going to use some sort of code stripper thingy which gets rid
> > generics for backwards source compatibility?

> No, not as far as the conversation is going.

> > Bear in mind that SDKs <=1.4
> > inspired this library due to perceived shortcomings in the reference
> > implementations of the collection framework interfaces.  It seems
> > counterintuitive to make SDKs >= 1.5 the only platform on which this
> > compile.  But as long as the binaries stay backwards-compatible, that's
> >
> Why bother?  The current collections serve very well for <=1.4. The
> major pain is coming from 1.5 users having to suppress warnings all over
> the place if they want to use commons-collections.
> I understand that the binary break will limit the backwards
> compatibility, but if you're needing to develop for 1.4 and 1.5, use 1.4
> libs.  As far as I see, most people leap to Java 5 rather than tip

First, let me understand the proposal.  Is a 1.4 compatible version of
commons-collections going to continue to be supported simultaneously with
the 1.5+ "reboot"?  Your answer above indicates "no".

If the answer is in fact "no", you answered your own question ("Why
bother?") with "if you're needing to develop for 1.4 and 1.5, use 1.4
libs."  You raised a very good reason to bother.  However, if the answer is
"yes", I can go away happy and stop bothering everyone with large codebase
maintenance issues.

My perspective may not be common.  The GeoTools project has been under
development for years.  It is modular and has many many separate
developers, some of whom have moved onto greener pastures.  The "official"
policy is that we develop for Java 5 now.  Yet there is a sizable code base
developed during the time of 1.4.  Although we have our Java 5 advocates,
there is no one with the budget of time or money to pull the entire code
base forward simultaneously.  So if it happens at all, it must happen by
means of "tip toeing".  Veteran, well-tested code may eventually be phased
out, but realistically we're talking years.  We may see Java 1.8 before the
last of 1.4 is phased out.  We just don't have the developer power to
factor in the latest compiler toys every two years (and deal with the new
bugs introduced by the process), no matter how shiny the new toys are.

Ergo, we need access to quality 1.4 libraries for the foreseeable future.


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

View raw message