Java "NoSuchMethodError" - Fix Dependency Version Conflicts in CI

NoSuchMethodError means the JVM loaded a class but the exact method signature your code calls is not in the version that is actually on the runtime classpath. It is the classic symptom of conflicting library versions ("jar hell").

What this error means

The run throws java.lang.NoSuchMethodError naming a method and signature that exists in the version you built against but not in the one resolved at runtime. It is deterministic for a given dependency graph.

Exception in thread "main" java.lang.NoSuchMethodError:
'com.google.common.base.Splitter com.google.common.base.Splitter.omitEmptyStrings()'
	at com.example.Parser.split(Parser.java:21)

Common causes

Two versions of the same library on the classpath

A transitive dependency pulls an older (or newer) version of a library; the resolved version lacks the method your code was compiled against.

Provided vs bundled version mismatch

The runtime environment supplies a different version of a library than the one you compiled with, so the method signature no longer matches.

How to fix it

Find and align the conflicting version

1. Print the dependency tree and locate every version of the library in question.
2. Force a single version (dependency management / constraints) that contains the method.
3. Rebuild and confirm only one version resolves at runtime.

mvn dependency:tree -Dincludes=com.google.guava:guava
# or for Gradle:
./gradlew :app:dependencyInsight --dependency guava

Pin the version explicitly

Use dependency management to lock the library to one known-good version across the whole build.

dependencies {
  constraints {
    implementation("com.google.guava:guava:33.2.1-jre")
  }
}

How to prevent it

• Use BOMs or dependency constraints to keep one version of each library.
• Watch the dependency tree for duplicate libraries at different versions.
• Compile and run against the same library versions.

Related guides