Import a safe class from JAR files

Question

Consider a scenario in which a java program imports classes from jar files. If the same class is in two or more jar files, a problem may occur.

• In such scenarios, which class is the program importing? This is a class with an older timestamp.

• What are the methods we can follow to avoid such complications.

Edit: This is an example. I have 2 jar files my1.jar and my2.jar. Both files contain com.mycompany.CrazyWriter

Answer 1

Firstly, I assume that you mean that the same class is in two jar files ...

Now, answering your questions:

• Which class is imported depends on your classloader and JVM. You cannot guarantee what class it will be, but in a regular classloader it will be the class from the first jar file in your class path.
• Do not put the same class in multiple jar files, or if you are trying to override system classes, use -bootclasspath .

Change To refer to one of the comments on this answer. Initially, I thought that sealing the jar would make a difference, since theoretically it should not load two classes from the same package from different jar files. However, after some experimentation, I see that this assumption is not fulfilled, at least with the default security provider.

Answer 2

By default, classes are loaded by ClassLoader using the classpath method, which runs in order.

If you have two implementations of the same class, the first class loader will be loaded.

If the classes are not actually the same class (the same names, but different methods), you will get an exception when you try to use it.

You can load two classes with the same name in the same virtual machine using several class loaders. The OSGI framework can manage many complexitites for you, make sure the correct version is loaded, etc.

Answer 3

ClassLoader is responsible for loading classes. It scanns ClassPath and loads the class that it found first. If you have the same Jar twice on ClassPath, or if you have two Jars that contain two different versions of the same class (this is com.packagename.Classname), the one that was found first is loaded.

Try to avoid using the same banner in the class path twice.

Answer 4

• Not sure what you mean by "the same class as in the two classes"

  If you were referring to inner / nested classes, there shouldn't be a problem, since they are in different namespaces.
  If you meant two more JARs, as already mentioned, the order in the classpath is used.

• How to avoid?
  A package must be in only one JAR to avoid class duplication. If two classes have the same simple name, for example java.util.Date and java.sql.Date , but are in different packages, they are actually different classes. You must use the full name of at least one of the classes to distinguish them.

Answer 5

If you have a problem determining which version of the class is being used, then jwhich may be useful: http://www.fullspan.com/proj/jwhich/index.html

Answer 6

If the same class is in two more jars, the problem should be.

What do you mean? Why should be a problem?

In such scenarios, which class is the program importing? (Class with old timestamp?)

If the class exists in two JARs, the class will be loaded from the first JAR in the class path where it is found. Citation Setting the class path (the cited part also applies to archive files):

Important is the order in which you specify multiple path path entries. The Java interpreter will search for classes in directories in the order they appear in the class path variable. In the above example, the Java interpreter first looks for the desired class in the C:\java\MyClasses . Only if he does not find a class with his own name in this directory, the interpreter will look in the C:\java\OtherClasses .

In other words, if a specific order is required, simply list the JAR files explicitly in the class path. This is what is commonly used by application server providers: to fix certain product classes, you put a JAR (for example, CR1234.jar ) containing the corrected classes (classes) in the class path to the main JAR (say weblogic.jar ).

What methods can we follow to avoid such complications.

Well, the obvious answer is not to do this (or just as intended, as in the above example).