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

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 multipleincompatible dependencies if possible.


Each classload picks exactly one class. Usually the first one found.

OSGi aims to solve the problem of multiple versions of the same jar. Equinox and Apache Felix are the common open-source implementations for OSGi.


Classloader will load classes from the jar that happened to be in the classpath first.Normally, incompatible versions of library will have difference in packages,But in unlikely case they really incompatible and can't be replaced with one - try jarjar.