commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject [PROPOSAL] Major versions require package name change
Date Sun, 29 Oct 2006 11:35:02 GMT
The major version number of a component, where it is greater than 1, 
shall be included in the package name.

org.apache.commons.pool - version 1.x line
org.apache.commons.pool2 - version 2.x line

Java has no mechanism for handling different versions of the same 
library where those versions clash. This leads to a situation known as 
'jar hell'.

Consider application A dependent on frameworks M and N, both of which 
depend on a commons component X.

       |   |
       M   N
       |   |

Now consider what happens if framework M upgrades to a later version of 
X, but N does not. The standard approach is to drop in X2 and hope that 
N still runs.

       |   |
       M   N
       |   |

However N may not run with X2 if the changes from X to X2 are major and 
incompatible (which should be signalled via a major version change).

Given this situation, the application now has no simple options. They can:
a) give up and not upgrade framework M
b) petition framework N to upgrade
c) dive into the open source and upgrade N themselves
d) use two classloaders
e) use fancy bytecode weaving tricks to merge the versions
f) use jar embedding tools to alter N

I would argue that the majority of developers would choose option (a) 
and give up. This is because while options b-f are possible, they are 
not what the average *user* wants to spend their time doing.

Of course, all of this presents a very simple example. Most open source 
stacks are much deeper than this and thus the potential for jar hell is 
much higher.

The proposed solution is to rename the package of each commons component 
at each major version change. This binds all the callers of the commons 
component to a different package namespace, and thus no clashes, or jar 
hell will ensue - except by human error.

Why now? Because this is the time that the majority of components are 
starting to consider new incompatible versions, often related to JDK1.5.

- The client application has to change their package names when 
upgrading to a later major version of the commons component.

- The client may get two versions of the same class in their IDE 
autocomplete (most IDEs allow this to be filtered).

This proposal is about making upgrades *predicatable* at the expense of 
a small amount of pain. I know that most of us don't really like it, but 
I contend that there is no alternative other than to inflict pain on 
users of commons over the next few years, and perhaps risk commons 
becoming irrelevant by being unusable. I also strongly believe we need a 
cross-commons approach on this.


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

View raw message