假設我編譯我的類并lib_v1.0.jar分發(fā)我的二進制文件。然后我更新到lib_v1.1.jar.?假設我的源代碼針對 v1.1 進行編譯而沒有錯誤，那么我的舊分布式二進制文件是否始終可以使用lib_v1.1.jar，或者我是否必須重新編譯和重新分發(fā)新的二進制文件？
4 回答
烙印99
TA貢獻1829條經(jīng)驗 獲得超13個贊
源兼容性并不意味著二進制兼容性。
例如，我們在庫中有以下接口：
// jar v1.0
interface Service {
int calculate(); // signature: ()I
}
我們從代碼中調(diào)用它：
Service service = ...
int a = service.calculate(); // calls calculate()I method
在版本 v1.1 中，庫代碼略有更改：
// jar v1.1
interface Service {
Integer calculate(); // signature: ()Ljava.lang.Integer;
}
由于自動裝箱，源代碼仍然兼容，但是如果我們使用新的庫版本運行代碼，它將失敗并出現(xiàn) java.lang.NoSuchMethodError: Service.calculate()I 錯誤。
類似的問題可能是由 lambda 作用域、泛型轉(zhuǎn)換、隱式類型轉(zhuǎn)換等引起的。
撒科打諢
TA貢獻1934條經(jīng)驗 獲得超2個贊
假設我的源代碼針對 v1.1 進行編譯且沒有錯誤，我的舊分布式二進制文件是否始終可以工作
你應該相對安全，只要你的代碼不使用反射，例如通過名稱實例化類，或者非常糟糕，通過“后門”訪問私有字段。當然，反射都是在運行時發(fā)生的，所以“我的使用反射的代碼仍然可以編譯”對您沒有任何幫助?；蛘呷鐖D所示，只要第 3 方 API 中的更改不是關于編譯器將優(yōu)雅地忽略的簽名更改，例如將 int 轉(zhuǎn)換為 Integer，如其他答案中所述。
話雖如此：真正的問題不是“它編譯”。真正的問題是：它仍然按預期運行嗎？
而這個問題無法通過編譯來回答。
因此，讓我們增強您的陳述：
假設我的源代碼針對 v1.1 進行編譯而沒有錯誤，并且我編寫的所有單元和集成測試都是為了確保我的代碼在針對 v1.1 運行時能夠正確地讓第 3 方庫全部通過...
那么你就可以非常安全了。除非你忘記了一些重要的測試用例。
但基本上，無論您的產(chǎn)品使用 v1.0 還是 v1.1，您對產(chǎn)品的質(zhì)量都有類似的信心。因為即使使用 v1.0，您仍然可能會遇到明天會出現(xiàn)關于您以前從未見過的問題的錯誤報告，只是因為這種情況很少發(fā)生。
一只名叫tom的貓
TA貢獻1906條經(jīng)驗 獲得超3個贊
不，不是的。使用更改后的常量將是不正確的。
考慮庫中的這個常量字段：
package com.example.lib;
public class LibConstants {
public static final int MAX_THREADS = 8;
}
Java 編譯器在編譯時替換常量。 如果您的代碼如下所示：
someLibClass.startServer(LibConstants.MAX_THREADS);
Java 會將其編譯為：
someLibClass.startServer(8);
如果庫的更高版本更改了該常量：
public class LibConstants {
public static final int MAX_THREADS = 20;
}
您的代碼將不會使用常量的新值，因為編譯器在編譯代碼時刪除了對靜態(tài)字段的任何引用。
添加回答
舉報
0/150
提交
取消