PROPOSAL:
The major version number of a component, where it is greater than 1,
shall be included in the package name.
EXAMPLE:
org.apache.commons.pool - version 1.x line
org.apache.commons.pool2 - version 2.x line
RATIONALE:
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.
A
|
-----
| |
M N
| |
-----
|
X
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.
A
|
-----
| |
M N
| |
-----
|
X2
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.
DOWNSIDES:
- 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.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
