You've spent an hour writing a beautiful piece of logic. It compiles perfectly. You hit "Run," and then this hits you in the face:

java.lang.NoSuchMethodError: 'com.fasterxml.jackson.databind.ObjectMapper.readValue(java.lang.String, java.lang.Class)
    at com.example.MyService.parseJson(MyService.scala:12)
    at com.example.Main.main(Main.scala:5)

This is one of the most frustrating errors in the JVM ecosystem. If you're seeing this, it means the code you compiled against is not the code that is actually running. Your compiler saw a method that existed in version X of a library, but at runtime, the JVM loaded version Y, which doesn't have that method. You've just hit a dependency conflict.

The ghost in the dependency graph

How does this even happen? In Scala, we rarely use just one library. We use a library, which uses another library, which uses another. This is your dependency graph. The conflict happens when two different libraries in your graph depend on different versions of the same third library.

Let's say you're using a library for HTTP requests (like sttp) and a library for JSON processing (like jackson-module-scala). It might look like this in your build.sbt:

libraryDependencies ++= Seq(
  "com.softwaremill.sttp.client3" %% "core" % "3.9.0",
  "com.fasterxml.jackson.module" %% "jackson-module-scala" % "2.15.2"
)

On the surface, this looks fine. But sttp might internally depend on jackson-databind version 2.12, while your explicit jackson-module-scala dependency pulls in 2.15. SBT usually tries to resolve this by picking the newest version (eviction), but sometimes that "win" creates a binary incompatibility where a method signature changed between versions. Now you have a runtime crash despite a clean compile.

Finding the culprit with dependencyTree

You can't fix what you can't see. I don't guess where these conflicts are; I map them. If you're using SBT, the best way to diagnose this is by using the sbt-dependency-graph plugin (which is built-in for newer SBT versions).

Run this in your terminal:

sbt dependencyTree

You're looking for lines that show an "eviction." You'll see something like [evicted] next to a version number. This tells you exactly which library is fighting over which version. I usually pipe the output to a file or grep for the specific package (e.g., grep "jackson-databind") to find the clash. Once you identify that Library A wants v2.12 and Library B wants v2.15, you have to make a decision.

Forcing a version with dependencyOverrides

You have a few options here. You could try to exclude the transitive dependency from one of the libraries, but that's like playing Whac-A-Mole—you fix one, and another pops up. When I need to tell SBT, "I don't care who wants what, use THIS version," I use dependencyOverrides.

Add this to your build.sbt:

dependencyOverrides ++= Seq(
  "com.fasterxml.jackson.core" % "jackson-databind" % "2.15.2"
)

dependencyOverrides is a heavy hammer. It tells SBT to ignore its usual conflict resolution strategy and force a specific version across the entire project, regardless of what the transitive dependencies demand. In the case of Jackson, forcing the newer version usually works because Jackson maintains decent backward compatibility. If you force an older version and a library actually needs a newer feature, you'll just shift the NoSuchMethodError to a different line of code.

I recommend starting with dependencyOverrides for core libraries like Jackson, Netty, or Cats. It keeps your build file honest and ensures your runtime environment matches your expectations.

📋 Practical Task

Exercise: Resolving the Log4j Version Clash

You are working on a legacy project that uses an old logging wrapper and a modern cloud-SDK. Your project compiles, but when you start the application, it crashes with a java.lang.NoSuchMethodError originating from org.apache.logging.log4j.core.config.ConfigurationFactory.

Your current build.sbt looks like this:

scalaVersion := "2.13.12"

libraryDependencies ++= Seq(
  "com.legacy.system" % "old-logger-wrapper" % "1.0.4", // Internally depends on log4j-core 2.10.0
  "com.modern.cloud" % "cloud-sdk" % "5.2.1"           // Internally depends on log4j-core 2.20.0
)

Your Goal: Use the dependencyOverrides mechanism to force the project to use log4j-core version 2.20.0, ensuring the modern SDK has the methods it needs to function.

Requirements:

• Modify the build.sbt to include the necessary override.
• Ensure you use the correct module coordinates for org.apache.logging.log4j.