Using classes with same name but different logic

Question

I have two jars for zookeeper . One is the official one and the other is a modified one which has only the implementations for using zookeeper with LDAP. Now there is a class called ZooDefs which is in org.apache.zookeeper .

This class is present in both the jars but the modified jar has one more variable included in it.

Now I want to use that variable in my code but I am totally clueless as to how to use it.

I referred this . But this has two different package names. But the jars I am dealing with have the same names, except for the logic inside them. I know this is totally wrong in terms of best practices , but I am asked to deal with this.

Please suggest how to deal with this.

Answer 1

Here you go...

Project -> Properties -> Java Build Path -> Order and Export ... And you can reorder whichever jar you want first...

Answer 2

Usually, when you're not confident about how class loading works, it's not a good idea to have multiple JARs containing classes with the same FQDN. This is because JARs aren't logical units in terms of class loading and they aren't versioned (don't get fooled by filenames like mylibrary-1.0.0.jar, those are only file names), plus class loading happens "secretly" in the background and without having explicit control over it you can't be sure which physical files will get loaded when you refer to a class. This could lead to a host of strange errors ranging from silent errors through NullPointerExceptions to NoClassDefFoundErrors.

Under normal circumstances, ie. when each class is present only once, this means no problem because when you refer to a class, the class loader will find only one instance of that class on the class path so it can be considered deterministic.

In your case, an easy solution would be simply replacing the original JAR with the modified one where the modified has all the classes the original has (and they are backwards-compatible too). Of course, this could possible mean that you need to slightly change your build process, for example installing your version of zookeeper into your local Maven repository and use that version.

A more advanced (and more interesting) solution could be using OSGi (or other class loader-magic frameworks). OSGi works by adding extra package metadata to the manifest where you can specify bundle ID-s and version numbers. This allows loading multiple classes with the same FQDN but with different version numbers.

While Eclipse and other IDEs often offer the ability to declare the order of imports, this isn't the best solution because they rely on they have control over the class loading mechanism. This means, for example, when you build a runnable JAR and run it outside your IDE, your application might start failing because they have little to no control over class loading happening outside of them.