...
If there are multiple versions of the same class on the classpath, there's no guarantee which version will be loaded, so in general the classpath should only ever contain a single version of each class.
What is jar-hell ?
Suppose project A depends on the jars B and C, and these in turn depend on jar D. So the classpath consists of (A,B,C,D). No problem so far.
D is updated to add some new features (call it D2), and jar B is updated to use them (B2). Provided that D2 is binary compatible with D, the a classpath which contains (A,B2,C,D2) will still allow jar C to work correctly.
Now suppose that D2 is not compatible with D, such that jar C does not operate with jar D2. The classpath would have to contain both D and D2. However B2 requires the class from D2, wheres C requires the version of the class from jar D. It's not possible to satisfy both of these. Even for compatible classes in D and D2, there is a problem, because there's no way to determine whether classes will be loaded from D or D2.
Jar-hell is when the classpath needs to contains multiple copies of the same classes in different jars.
Maven dependency resolution
...
This can cause a problem, for which there are several possible solutions - none neither of which are is ideal: *
- use relocation POMs
...
- change the Foo package name
Relocation POMS
A relocation POM can be set up to redirect references from commons-foo:commons-foo to org.apache.commons:commons-foo. Both would be seen as being the same item, avoiding duplicates on the classpath.
...