Does Java classpath different order give "No Method found error"

Question

I have a Scala Akka Application which connects to HBase (currently CDP earlier HDP) deployed on rancher; Never faced any trouble when connecting to HDP hbase; Since recent HDP to CDP change, with the same image we are getting no method found on one of the dependency's class in one of the container, where as another container of same image connects to hbase properly.; even though the jar exists in the same image and classpath also.

one of the noticeable difference is change in the order of classpath.

1. Does change in the classpath order will effect the jars availability.
2. Does java libraries/classes would load in different order when they would hit a faster CPU cycle at startup.

What could be the reason for such "no class method found".

Answer 1

My bet is that there is another version of the jar somewhere in CDP, and occasionally it is loaded before the version that you ship with your project, causing the error.

So, when your container starts, try logging from which location the conflicting class is loaded. This question might help you: Determine which JAR file a class is from

Answer 2

It certainly can, if the same class file is present in different classpath entries. For example, if your classpath is: java -cp a.jar:b.jar com.foo.App, and:

a.jar:

pkg/SomeClass.class

b.jar:

pkg/SomeClass.class

Then this can happen - usually because one of the jars on your classpath is an older version than the other, or the same but more complicated: one of the jars of your classpath contains a whole heap of different libraries all squished together and one of those components is an older version.

There are some basic hygiene rules to observe:

1. Don't squish jars together. If you have 500 deps, put 500 entries on your classpath. We have tools to manage this stuff, use them. Don't make striped jars, uber jars, etc.
2. Use dependency trackers to check if there are version difference in your dependency chain. If your app depends on, say, 'hibernate' and 'jersey', and they both depend on google's guava libraries, but hibernate imports v26 and jersey imports v29, that's problematic. Be aware of it and ensure that you explicitly decide which version ends up making it. Presumably, you'd want to explicitly pick v29 and perhaps check that hibernate also runs on v29*. If it doesn't, you have bigger problems. They are fixable (with modular classloaders), but not easily.

*) Neither hibernate nor jersey actually depend on guava, I'm just using them as hypothetical examples.

For example, if you use maven, check out the enforcer plugin. (groupId: org.apache.maven.plugins, artifactId: maven-enforcer-plugin).