commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <>
Subject Re: [collections] Generifying Collections
Date Wed, 25 Oct 2006 14:46:35 GMT
On 10/21/06, Stephen Colebourne <> wrote:
> Henri Yandell wrote:
> > Why not just start a branch within Collections?
> >
> > I don't see why this is a new component, are we going to be advising
> > people to use Collections 3.x on JDK 1.5+ for any reasons other than
> > legacy or instability of our generified version?
> >
> > My view is to make a collections-generics branch in collections with a
> > view to it being Collections 4.0.
> Because commons isn't like other OSS projects. We can't go around
> changing our APIs freely, even between major versions. Its a simple case
> of us being at the bottom of the stack of jars. If we do change an API,
> any API then jar hell ensues because higher OSS projects will clash on
> their required versions of [collections].
> Thus, it has to be a new package, and this is best thought of as a new
> component.
> (Compare this with the JDK where they had to jump through ridiculous
> hoops to make generics fully backwards-compatible, and created a
> half-arsed mess in the process...)

>From a simplistic user perspective seems to me that the compatibility
achieved by the JDK is successful. I don't understand the intricacies
required to generify a library, but if we could do the same wouldn't
this be the best solution from a user perspective?

Perhaps you could expand on what the issues are with the JDK approach
and why they're not desirable in Commons Collections - when I look at
the differences for example between the generified and non-generified
versions of java.util.List, I don't see the mess you describe.

Also I don't understand the compatibilty issue - does the following,
for example, constitute a break in compatibility?

Going from:
    boolean add(object o)
   boolean add(E e)

Apologies if these are stupid questions, but seems to me that if we
could retain backwards compatibility it would be the optimum solution
from a user perspective.


> Stephen

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

View raw message