How to Detect and Resolve Netty Jar Version Conflicts with Arthas

When you notice that a project loads multiple versions of Netty jars, typical symptoms include java.lang.NoSuchMethodException , java.lang.NoClassDefFoundError , and java.lang.ClassNotFoundException . These errors often appear on a server even though the code runs locally, indicating a jar version conflict.

Inspecting Loaded Classes and Methods with Arthas

Install and start the open‑source Arthas diagnostic tool:

curl -O https://arthas.aliyun.com/arthas-boot.jar
java -jar arthas-boot.jar

After Arthas starts, it lists running Java processes. Choose the target process by its number, for example:

[INFO] arthas-boot version: 3.4.6
[INFO] Process 40611 already using port 3658
[INFO] Process 40611 already using port 8563
[INFO] Found existing java process, please choose one and input the serial number of the process, eg : 1. Then hit ENTER.
* [1]: 40611 chapter4-3-0.0.1-SNAPSHOT.jar
  [2]: 37786

Two useful Arthas commands are:

sc – searches for classes matching a pattern. Example:

[arthas@40611]$ sc com.didispace.*
com.didispace.chapter43.Chapter43Application
com.didispace.chapter43.Chapter43Application$EnhancerBySpringCGLIB$8b82b194
com.didispace.chapter43.UploadController
Affect(row-cnt:3) cost in 6 ms.

sm – shows methods of a specific class. Example:

[arthas@40611]$ sm com.didispace.chapter43.UploadController
com.didispace.chapter43.UploadController <init>()V
com.didispace.chapter43.UploadController create(Lorg/springframework/web/multipart/MultipartFile;)Ljava/lang/String;
com.didispace.chapter43.UploadController uploadPage()Ljava/lang/String;
Affect(row-cnt:3) cost in 5 ms.

Finding and Resolving the Conflict

Run Maven’s dependency tree with verbose output to locate the conflicting jar: mvn -U dependency:tree -Dverbose The command prints a hierarchical list of all dependencies; search the output for duplicate versions and note which parent dependency brings them in.

There are two main ways to resolve the conflict:

Exclude the unwanted version in pom.xml using <exclusions>:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jdbc</artifactId>
    <exclusions>
        <exclusion>
            <groupId>xxx</groupId>
            <artifactId>yyy</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Force a specific version of the dependency directly in pom.xml, which has the highest precedence and prevents transitive versions from being pulled in.

After applying the exclusion or version override, rebuild the project and verify with Arthas that the correct classes are now loaded.

By following these steps you can quickly identify which Netty (or any other) jar version is being used at runtime and eliminate version clashes that cause obscure NoSuchMethod/NoClassDef errors.