Java, Classpath, Classloading => Multiple Versions of the Same Jar/Project

Java, Classpath, Classloading = Multiple Versions of the same jar/project

Classloader related problems are a quite complex matter.
You should in any case keep in mind some facts:

• Classloaders in an application are usually more than a single one. The bootstrap class loader delegates to the appropriate. When you instantiate a new class the more specific classloader is invoked. If it does not find a reference to the class you are trying to load, it delegates to its parent, and so on, until you get to the bootstrap class loader. If none of them find a reference to the class you are trying to load you get a ClassNotFoundException.

• If you have two classes with the same binary name, searchable by the same classloader, and you want to know which one of them you are loading, you can only inspect the way that specific classloader tries to resolve a class name.

• According to the java language specification, there is not a uniqueness constraint for a class binary name, but as far as I can see, it should be unique for each classloader.

I can figure out a way to load two classes with the same binary name, and it involves to have them loaded (and all their dependencies) by two different classloaders overriding default behaviour.
A rough example:

    ClassLoader loaderA = new MyClassLoader(libPathOne);
    ClassLoader loaderB = new MyClassLoader(libPathTwo);
    Object1 obj1 = loaderA.loadClass("first.class.binary.name", true)
    Object2 obj2 = loaderB.loadClass("second.class.binary.name", true);

I always found classloader customization a tricky task. I'd rather suggest to avoid multiple
incompatible dependencies if possible.

what happens if we put two different versions of jar files in classpath?

While I also recommend not to do this, I still like to try to answer your original question:

Java has a classloader hierarchy, so if you have both JARs in different levels of the hierarchy, the classloader defines its precendence. Most popular example is the web application classloader hierarchy (Tomcat for example), where application classes have a higher priority than the comtainer classes (if both are applicable).

If you have both JARs in the same classloader (same level), the filesystem determines the order, which is unreliable from the developer's point-of-view, so consider it to be random. Only one loads, but you don't know which, and will maybe not even get errors from dependency problems. If you get dependency problems, they may be java.lang.Errors, such as VerifyError, NoClassDefFoundError, NoSuchMethodError.

Java - how to load different versions of the same class?

You're going the right way. You must take some things into account.

The normal thing is classes that exist in parent classloaders are used. So if you want two versions those classes must not be there.

But if you want to interact you can use reflection, or even better a common interface. So I'll do this:

common.jar:
BaseInterface

v1.jar:
SomeImplementation implements BaseInterface

v2.jar:
OtherImplementation implements BaseInterface

command-line:
java -classpath common.jar YourMainClass
// you don't put v1 nor v2 into the parent classloader classpath

Then in your program:

loader1 = new URLClassLoader(new URL[] {new File("v1.jar").toURL()}, Thread.currentThread().getContextClassLoader());
loader2 = new URLClassLoader(new URL[] {new File("v2.jar").toURL()}, Thread.currentThread().getContextClassLoader());

Class<?> c1 = loader1.loadClass("com.abc.Hello");
Class<?> c2 = loader2.loadClass("com.abc.Hello");

BaseInterface i1 = (BaseInterface) c1.newInstance();
BaseInterface i2 = (BaseInterface) c2.newInstance();

Java how to use multiple versions of one library maybe using classloaders

No classloader magic needed. The wanted mechanism from maven is called relocation.
Relocations can change the package of a library at compile time to prevent conflicts. Using this you can relocate com.google.commons to my.shaded.version.com.google.commons for example and prevent conflicts.

https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html

How do I fix a NoSuchMethodError?

Without any more information it is difficult to pinpoint the problem, but the root cause is that you most likely have compiled a class against a different version of the class that is missing a method, than the one you are using when running it.

Look at the stack trace ... If the exception appears when calling a method on an object in a library, you are most likely using separate versions of the library when compiling and running. Make sure you have the right version both places.

If the exception appears when calling a method on objects instantiated by classes you made, then your build process seems to be faulty. Make sure the class files that you are actually running are updated when you compile.

---

Related Topics