完整工程示例見：no_such_method
背景
在開發中常遇到拋出NoSuchMethodError的情景，但想不通找不到方法的問題為什么可以通過編譯階段，所以創建了三個工程來模擬出NoSuchMethod的場景進行研究。
模擬NoSuchMethodError
這里簡單的復現了NoSuchMethodError出現的場景：outer有1.0和2.0兩個不兼容的版本，caller依賴于outer的2.0版本，而main中又顯式指出了outer的1.0版本，執行main中的主方法即報錯。
下面是main的依賴樹：
[INFO] com.example:main:jar:1.0-SNAPSHOT
[INFO] +- com.example:caller:jar:1.0:compile
[INFO] \- com.example:outer:jar:1.0:compile
步驟
1. 生成1.0版本的outer
1.1 創建Painter類，其中包含一個接收String類型的print方法。
package org.example;
public class Painter {
// 1.0
public static void print(String name) {
System.out.println("Hello " + name);
}
}
1.2 設置pom中的version為1.0
1.3 運行mvn clean install安裝到本地倉庫
2. 生成2.0版本的outer
2.1 更新Painter類，更新print方法，改為接收一個Integer類型的參數。
package org.example;
public class Painter {
// 1.0
//public static void print(String name) {
// System.out.println("Hello " + name);
//}
// 2.0
public static void print(Integer i) {
System.out.println("Hello NO." + i);
}
}
2.2 設置pom中的version為2.0
2.3 運行mvn clean install安裝到本地倉庫
3. 創建caller
3.1 caller依賴于2.0版本的outer，pom片段如下
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>outer</artifactId>
<version>2.0</version>
</dependency>
</dependencies>
3.2 創建Caller類，調用2.0版本outer中的Painter
package com.example;
import org.example.Painter;
public class Caller {
public static void call() {
Painter.print(1);
}
}
3.3 運行mvn clean install安裝到本地倉庫
4. 創建main
4.1 設置pom依賴如下
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>caller</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>com.example</groupId>
<artifactId>outer</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
4.2 新建Main類，其中有main方法來調用Caller中的靜態方法
package com.example;
public class Main {
public static void main(String[] args) {
Caller.call();
}
}
4.3 編譯mvn compile -X，我們可以看到最終使用的outer版本為1.0，并且并沒有報錯
[DEBUG] com.example:main:jar:1.0-SNAPSHOT
[DEBUG] com.example:caller:jar:1.0:compile
[DEBUG] com.example:outer:jar:1.0:compile
[INFO] BUILD SUCCESS
4.4 運行main中的主函數，拋出NoSuchMethodError，命令為mvn exec:java -Dexec.mainClass="com.example.Main" -X，結果如下
java.lang.NoSuchMethodError: org.example.Painter.print(Ljava/lang/Integer;)V
at com.example.Caller.call (Caller.java:7)
at com.example.Main.main (Main.java:5)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:282)
at java.lang.Thread.run (Thread.java:748)
原因分析
為什么編譯時不報找不到方法呢？
因為依賴的jar已經編譯過，無需再編譯，所以不報錯。或者說，編譯過程中只會檢查當前java文件的正確性，不會關心依賴的class的正確性。而在運行時則動態加載類，才發現找不到方法，故拋出NoSuchMethodError。
驗證
將Main反編譯，使用命令javap -c com.example.Main，結果如下
Compiled from "Main.java"
public class com.example.Main {
public com.example.Main();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: invokestatic #2 // Method com/example/Caller.call:()V
3: return
}
可以看到main的編譯過程中并沒有涉及到對outer工程中Painter#paint方法的引用，所以不會在編譯期間發現這個問題。
而如果使用1.0版本的outer作為caller的依賴，則在編譯時就會報異常，編譯命令：mvn clean compile，異常片段如下
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project caller: Compilation failure
[ERROR] /no_such_method/caller/src/main/java/com/example/Caller.java:[7,23] 不兼容的類型: int無法轉換為java.lang.String
