Java "java.lang.NoSuchMethodError" in CI - Fix the Dependency Conflict
NoSuchMethodError almost always means a binary-compatibility mismatch: your code (or a library) was compiled against a method signature that the version actually on the runtime classpath does not have. It is a version conflict, not a code typo.
What this error means
A run or test throws java.lang.NoSuchMethodError: 'com.google.common.base.Strings.lenientFormat(...)' or similar. It compiled fine because a different (newer) version was visible then; at runtime an older jar wins.
java.lang.NoSuchMethodError: 'void com.fasterxml.jackson.databind.ObjectMapper.<init>(com.fasterxml.jackson.core.JsonFactory)'
at com.example.JsonUtil.<clinit>(JsonUtil.java:9)
at com.example.JsonUtilTest.roundTrip(JsonUtilTest.java:14)Common causes
Two versions of the same library on the classpath
A transitive dependency pulls an older (or newer) version of a jar than the one your code was compiled against. The classloader picks one, and its method set does not match.
A managed version was overridden downstream
A BOM or another dependency downgrades a library, so the compiled call targets a method absent in the resolved version.
How to fix it
Find and pin the conflicting version
Inspect the dependency tree and force a single, compatible version.
# Maven: see who brings each version, then pin in <dependencyManagement>
mvn dependency:tree -Dincludes=com.fasterxml.jackson.core
# Gradle: print the resolution and pin
./gradlew dependencyInsight --dependency jackson-databindForce a consistent version with a BOM
Import the library BOM so all of its modules resolve to one aligned version.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.fasterxml.jackson</groupId>
<artifactId>jackson-bom</artifactId>
<version>2.17.1</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>How to prevent it
- Align library families via their BOM, run dependency convergence in CI, and avoid mixing major versions of the same library.