執行期間丟擲NoSuchMethodError模擬及原因分析

Recruit發表於2018-10-31
Error

執行期間丟擲NoSuchMethodError

完整工程示例見：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
複製程式碼

相關文章