NoSuchMethodError
Java Programming Language
Severity: CriticalWhat Does This Error Mean?
A NoSuchMethodError means Java found the class it was looking for, but the specific method it tried to call does not exist in that class at runtime. This almost always means a version mismatch — the code was compiled against one version of a library, but at runtime a different (older or incompatible) version of that library is loaded. The method existed when you compiled, but the library version now running does not have it.
Affected Models
- Java 8
- Java 11
- Java 17
- Java 21
- All Java versions
Common Causes
- Two different versions of the same library on the classpath — one version has the method, the other does not
- A dependency was updated in the build file but an old cached version is still being used
- The application was compiled with a newer library but deployed with an older one
- A JAR file was manually replaced with an older version in the deployment environment
- Conflicting transitive dependencies — two libraries both depend on the same third library but want different versions
How to Fix It
-
Read the full error message — it tells you the exact class and method signature that was not found. For example: 'java.lang.NoSuchMethodError: com.example.Foo.bar()V'. Write this down.
The signature at the end (like ()V or (Ljava/lang/String;)I) is bytecode notation. ()V means no arguments, returns void. (Ljava/lang/String;)I means takes a String, returns int.
-
Check which version of the library containing that class is on the classpath at runtime. Compare it to the version you compiled against.
In Maven: mvn dependency:tree shows all dependencies and their versions. Look for the library that contains the class from the error message.
-
Look for duplicate or conflicting versions of the same library. If two versions of the same JAR are both present, the wrong one may be loaded first.
In Maven, use <dependencyManagement> to force a specific version. In Gradle, use resolutionStrategy.force('group:artifact:version') to pin a dependency version.
-
Clean and rebuild the entire project from scratch. Delete the build output and all cached dependencies (mvn clean install or gradle clean build), then rebuild.
Sometimes stale cached JAR files from a previous version linger and cause this error. A full clean rebuild eliminates that possibility.
-
If deploying to a server (Tomcat, JBoss, WildFly), check the server's lib folder. Libraries placed there can override the ones in your WAR/JAR, potentially loading an incompatible older version.
The general rule: the runtime classpath must contain the same version of every library that the code was compiled against.
When to Call a Professional
NoSuchMethodError is an Error, not an Exception — it signals a serious JVM-level problem. It always means a dependency version conflict or mismatch between compile-time and runtime libraries. This requires investigating your build configuration and deployment environment.
Frequently Asked Questions
NoSuchMethodError vs NoSuchMethodException — what is the difference?
NoSuchMethodError is thrown by the JVM when a compiled bytecode reference to a method cannot be resolved at runtime — usually a version conflict. NoSuchMethodException is thrown by reflection code (like Method m = clazz.getMethod('foo')) when the specified method does not exist. Error = JVM-level, very serious. Exception = reflection API, handleable.
Why did my code compile successfully if the method does not exist?
Because it DID exist — at compile time. You compiled against version 2.0 of a library that has the method. But at runtime, version 1.5 of that same library is loaded (from a different location or a conflicting dependency), and it does not have the method. Compile time and runtime used different library versions.
Can NoSuchMethodError happen after a Java version upgrade?
Yes — when you upgrade the JDK, some internal Java methods change or are removed. Code that called internal APIs (like sun.misc.Unsafe methods) may get NoSuchMethodError on a newer JDK. Always test thoroughly after a JDK upgrade, especially in larger applications with many dependencies.