從 Java 8遷移到Java 11比大多數升級更棘手。以下是這個過程的一些注意事項。

模塊

在Java 9中Java引入了歷史上最大的變化之一 是模塊，但：

不必將你自己的代碼模塊化以后才能升級到Java 11。

在大多數情況下，放在類路徑classpath上的代碼能繼續在Java 9及更高版本上有效被發現和運行，但是如果將模塊放置類路徑上會被忽略，這對于庫包發布者來說非常糟糕，但對于應用程序開發者是個好事情。

因此，在升級到Java 11時盡可能地先不用模塊化，而將自己的應用程序轉換為Java模塊應該等待時機，等待大規模開源的依賴庫包真正采用模塊化后的幾年內才開始實施模塊化，現在，嘗試模塊化很痛苦，因為你的依賴包很少是模塊化的。

(如果將程序模塊化的主要原因是由于使用jlink能縮小JDK的大小，也完全不需要模塊化來實現這個目標 - 只需使用Maven創建一個 jar- with-dependencies

，其中module-info不配置require，不配置export( no-requires和no-exports )。

刪除了JDK的部分內容

JDK的有關Java EE和Corba的一部分被刪除，它們不再適合JDK，或者可以在其他地方維護。

如果您使用Corba，那么幾乎沒有人可以幫助你，但是，如果你使用Java EE模塊，那么在大多數情況下，對已刪除代碼的修復應該很簡單。只需添加適當的Maven即可。

在Java客戶端方面，已經刪除了Java WebStart ，替代方案會更加棘手，請考慮使用Getdown或Update4J。

不安全和朋友

多年來， Sun和 Oracle 一直在告訴開發人員不要使用sun.misc.Unsafe和其他尖端的JDK API。很長一段時間，Java 9將要刪除這些，但這實際上從未發生過。

但是在Java 11，首次訪問受限API時，你可能會收到警告，此警告僅打印一次。這是一個有用的提醒，你的代碼或依賴正在做一些“頑皮”的事情，需要在某個時候修復。

您還會發現Java 11有許多專門設計的新API，以避免使用Unsafe人需要，如果你使用的是“非法”API，請優先調查這些新API，例如， Base64， MethodHandles.privateLookupIn， MethodHandles.Lookup.defineClass， StackWalker 和Variable Handles。

工具和圖書館

模塊化和新的六個月發布周期這兩個機制共同對 工具 和庫開發人員使用產生了真正的影響，一些項目已經能夠跟上，有些人在努力，有些人失敗了。

升級到Java 11時，關鍵任務是將所有依賴項更新為最新版本，如果自Java 9問世以來這些依賴項還沒有發布新版本，那么這些依賴可能需要額外的關注或測試，確保您也更新了IDE。

但是，不僅需要更新應用程序的依賴項，Maven也是如此，大多數Maven插件已將主要版本更改為v3.x，將Maven本身升級到v3.5.4也是有益的。

可悲的是，核心maven團隊規模很小，因此仍有一些問題需要解決，但是，如果你的Maven構建非常合理且簡單，那么通常應該沒問題。但請注意，將插件從v2.x升級到v3.x可能需要更改配置，而不僅僅是與模塊相關聯。例如，Maven Javadoc插件已重命名該argLine屬性。

需要注意的一個關鍵點是Maven使用模塊進行操作的方式，當Maven編譯器或surefire插件找到一個模塊化的jar文件(即帶有module-info.class)時，它可以將該jar放在模塊路徑而不是類路徑上，因此，即使你可能打算只在類路徑上運行你的應用程序，Maven可能部分地在類路徑上編譯和測試代碼，而另外一部分會在模塊路徑上編譯代碼，在目前，沒有什么可以搞定這個問題。

有時你的構建需要更大的更改。例如，需要將Findbugs更改為SpotBugs，并將Cobertura改為JaCoCo。

這些構建更改可能需要一些時間 。

總結

當我完成遷移之后，我的結論是痛苦主要在于維護與Java 8的兼容性，將應用程序全部只到Java 11應該更簡單，因為不需要與Java 8保持聯系。

總結

以上是生活随笔為你收集整理的java 8 update 11_从Java 8升级到Java 11应该注意的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。