Java “NoSuchMethodError”

Question

I'm getting:

NoSuchMethodError: com.foo.SomeService.doSmth()Z

Am I understanding correctly that this 'Z' means that return type of doSmth() method is boolean? If true, then that kind of method really does not exist because this method returns some Collection. But on the other hand if I call this method, I'm not assigning its return value to any variable. I just call this method like this:

service.doSmth();

Any ideas why this error occurs? All necessary JAR files exist and all other methods from this class seems to exist.

Answer 1

Looks like method exists in classpath during compilation, but not during running of your application.

I don't think return type is a problem. If it was, it wouldn't compile. Compiler throws error when method call is ambiguous, and it is when two methods differ only by return type.

Answer 2

Normally, this error is caught by the compiler; this error can only occur at run time if the definition of a class has incompatibly changed.

In short - a class/jar file at runtime is not the same that you used at compile time.

Answer 3

This is probably a difference between your compile-time classpath and you run-time classpath.

Here is what seems to be going on:

• The code is compiled with a class path that defines the doSmth() method returning a boolean. The byte-code refers to the doSmth()Z method.
• At runtime, the doSmth()Z method isn't found. A method returning a Collection is found instead.

To correct this problem, check your (compile time) classpath.

Answer 4

The current reply just tell you why is failing. Usually is even nicer to know how to fix problems. As it is mentioned, the problem usually is that you built your program but when running or exporting it, the library is not included. So the solution is...

If you are running, check the the run configuration Select Run tab -> Run configurations -> Select the configuration you are running -> Check the Classpath tab -> Ensure the libraries you need are there

If you are exporting (for example a war file), follow this Select project -> Select properties -> Select Deployment Assembly -> Press Add -> Select Java Build Path Entries -> Select the libraries you want to be included in your exported file (for example a war file)

In both cases, ensure the library which you are referencing in included.

Other frequent problems for this error are not the right type of parameters or visibility but then, the compiler will detect the error before running. In this case, just check the documentation to match the function and package visibility, and ensure that the library is found in Java Build Path in your project properties.

Answer 5

Maybe still can help somebody, but this exception can happen also when you have on the classpath two classes in different jar files that have the same exact signature but they haven't the same public methods.

For example:

• On file mylibrary1.jar you have class com.mypackage.mysubpackage.MyClass with method doSmth()

• On file mylibrary2.jar you have class com.mypackage.mysubpackage.MyClass without method doSmth()

When searching the class, the classloader may find first mylibrary2.jar depending on the path precedence but can't find the method on that class.

Be sure you don't have the same package + class on two different files.

Answer 6

I noticed this problem occurring while testing some experimental changes in multiple linked projects, after updating them from SVN in Eclipse.

Specifically, I updated all projects from SVN, and reverted the .classpath file rather than edit it manually to keep things simple.

Then I re-added the linked projects to the path, but forgot to remove the related jars. This was how the problem occurred for me.

So apparently the run time used the jar file while the compiler used the project files.

Answer 7

Another way this can happen and is difficult to find:

If a signature of a method in an external jar changes in a way that there is no error found in the IDE because it's still compatible with how you call it the class might not be re-compiled.

If your build checks the files for changes and only then recompiles them, the class might not be recompiled during the build process.

So when you run it this might lead to that problem. Although you have the new jar, your own code expects still the old one but does never complain.

To make it harder it depends on the jvm if it can handle such cases. So in the worst case it runs on the test server but not on the live machine.