commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [collections] Generifying Collections
Date Wed, 25 Oct 2006 12:51:57 GMT
Stephen Colebourne wrote:
> > 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].
Henri wrote:
> I'm not convinced by that. What you're saying is that if we want to
> have a major API change in a component, that we need to change the
> package name so two pieces of code can sit side by side. If that's
> true, then we should do it for all major versions (as major API change
> is the defining factor of major version changing) and stay within the
> same component.
> Having a bit of deja vu - think we had this discussion 6 months ago

Actually it was over [net], and recently. And yes, its not nice, but a different package name
is all that we get given by Java at present. However, there are cases where a major version
change can be done without breaking backwards compatability - typically, where the only change
is to remove deprecations ([lang] 3?).

We could just say that its the responsibility of everyone using commons to repackage our code
into their package structure, but IMHO thats just not practical, and quite wasteful.

> Basically - we need to start putting the major version in our package
> names. I hate that, but I can see the need.
Yep, it sucks. Yep, its essential.

> So this would be a branch of collections, with a package name
> change to org.apache.commons.collections4.*.
Well, the number is dependent on the strategy we are trying to achieve:

a) using '4' would indicate that every major version will have a new package name, but then
you can't use a major version to just remove deprections (a compatible major version change)

b) using '5' would indicate the technology reason for the version. The package would be commons-collections5-1.0.

c) using '5' as the commons name - commons5-collections-1.0

I favour (b) as I view this as a fork of [collections] for a new technology. I believe the
language changes in JDK5 are significant enough to warrant a fork.

> Would be sweet to have a build system that could deal with moving
> source from org/apache/commons/collections/ to the correct directory
> and package name prior to compiing/source-packaging. Might be worth
> playing with some Ant scripts for that.
Not sure how that helps. The new JDK5 code will probably be a proper fork, with some significant
method name/class changes.


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

View raw message