CODEWITHSUNDEEP
javadependencies
Mykhaylo Adamovych
Mykhaylo Adamovych

Reputation: 20966

Class version issue in classpath

Imagine I'm developing module A with two dependencies for B and C. What if B depends on module D version 2.0 but C depends on D version 3.0. To make things worse let D-3.0 is not back compatible with D-2.0 (interfaces were changed for example) and B is not supported already and there is no new version of B which could work with new version of D.

Is there any way I could run A with B and C dependencies? Is there any way to have some class different versions to be correctly loaded and used from classpath?

Thanks for ideas.

Upvotes: 2

Views: 155

Answers (3)

Robin
Robin

Reputation: 24262

Whether this can be resolved is very dependent on the type of dependencies you have. If they are direct compile time dependencies, then you have a big problem and may have to do some redesign.

OSGi may help, but only if the dependencies are runtime and accessed via interfaces as OSGi services. In this way, each service used is created using its own defined dependencies (and versions) and only exposed to the user via the interface. The consumer will only have a dependency to that interface. Thus in your case, if you have only references to classes in B and C that do not have direct references to D, you should be able to utilize OSGi.

On the other hand, if you reference classes from both B and C that have direct references to classes from D, this will not solve your problem since your module will be forced to import packages with appropriate versions and your conflict will still exist.

Upvotes: 0

Peter Lawrey
Peter Lawrey

Reputation: 533580

You might find this repackaging tool useful. http://code.google.com/p/jarjar/ This allows you to rename a package. (Assuming the incompatible libraries have the same packages) Once you have renamed one or both you can use the different name to distigush which package/library you want to use.

I have seen this used to create a library which five different version of xerces, selectable by package. :P

NOTE: The JRE places embedded packages under com.sun.* with packages like com.sun.org.apache.*

Upvotes: 2

Nishant
Nishant

Reputation: 55866

OSGi is the way. : ) I am still learning this, but the least it does it solves this problem known as Jar Hell. See here http://www.osgi.org/About/WhyOSGi

Versioning - OSGi technology solves JAR hell. JAR hell is the problem that library A works with library B;version=2, but library C can only work with B;version=3. In standard Java, you're out of luck. In the OSGi environment, all bundles are carefully versioned and only bundles that can collaborate are wired together in the same class space. This allows both bundle A and C to function with their own library. Though it is not advised to design systems with this versioning issue, it can be a life saver in some cases.

Upvotes: 4

Related Questions