Home › Java exceptions › NoSuchMethodError

What it looks like

java.lang.NoSuchMethodError: 'void com.google.common.base.Preconditions.checkArgument(boolean, java.lang.String, java.lang.Object)'

Extends IncompatibleClassChangeError in java.lang.

What it means

Your code compiled against one version of a library, and at run time a different version is on the classpath that lacks the method with that exact signature. It is the classic symptom of dependency version conflicts, the so-called jar hell: two libraries need different versions of a third, and the build tool picks one. The message includes the full method signature, which tells you which library and which method.

Common causes

• Two dependencies pull different versions of the same library and the older one wins.
• A BOM or parent POM pins a version that is older than a library expects.
• An old jar bundled inside a shaded or fat jar overriding the newer one.
• Mixing artifacts from different releases of one framework, for example Spring modules at different versions.

How to fix it

1. Run mvn dependency:tree -Dverbose or gradle dependencyInsight --dependency name to see which versions compete.
2. Force a single version with dependencyManagement (Maven) or a constraint or resolutionStrategy (Gradle).
3. Align framework modules by importing the framework BOM.
4. Print where the class came from: Foo.class.getProtectionDomain().getCodeSource().

Broken and fixed

// compiled against Guava 31, runtime has Guava 20
Preconditions.checkArgument(ok, "bad %s", value);

<dependencyManagement>
  <dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>33.2.1-jre</version>
  </dependency>
</dependencyManagement>

🔎 Unravel the failing code 🔎 Unravel the fix

Debug it faster

Paste the whole stack trace into the stack trace beautifier to hide framework frames, jump to the root cause and find the first line of your own code. It runs in your browser, so the trace never leaves your machine.

Related exceptions