從JDK8升級到JDK11，看這篇就足夠了

時間 2019-11-12

標籤 jdk8 jdk 升級 jdk11 看這足夠欄目 Java 简体版

原文原文鏈接

原文地址：https://blog.codefx.org/java/java-11-migration-guide/。在原文的基礎上，增長了一些我遇到的具體的坑還有在特定場景下的解決方案，供你們參考html

一些背景

在背景知識，咱們會討論一些關於新的JDK Release週期，OpenJDK特性歸一化，LTS（Long-term support長期支持版本）的事情。java

1. 新的發佈週期

這個就能夠長話短說了，反正咱們知道以下兩點就好：linux

每六個月發佈一個大更新（就是每一年的3月還有9月）
對於每一個大版本更新，會有兩次小版本更新（在發佈後一個月或者四個月以後）

2. OpenJDK已能夠做爲新的線上標準JDK

在OpenJDK 11以前，Oracle JDK是你們廣泛運用於線上的JDK，OpenJDK的特性並不徹底，而且Oracle JDK號稱作了不少優化。在OpenJDK 11以後，Oracle JDK正式商用（開發不收費，可是運行線上業務收費）。可是與此同時，Oracle宣佈，OpenJDK與Oracle JDK在功能上不會有區別。而且，OpenJDK 11 RTS將會由紅帽社區進行維護。這樣，更加增長了可靠性與保證問題的及時解決。spring

咱們能夠在線上使用OpenJDK，開發時，使用任意的JDK。bootstrap

3. LTS（Long-term support長期維護）版本

對於商業版的JDK，不一樣的廠商都將長期維護版本定在JDK 11/17/23/...api

對於OpenJDK，社區說，對於這些版本，至少會提供四年的維護更新時間。每一個長期維護版本都會有一個固定的管理者，對於OpenJDK11，應該就是紅帽社區。如今源代碼搞定了，可是，咱們應該從哪裏獲取編譯好的OpenJDK呢？這個能夠交給AdoptOpenJDK，它會一直收集不一樣版本的OpenJDK以及全平臺的build好的OpenJDK安全

4. Amazon Corretto

AWS也提供了本身的OpenJDK，Amazon Corretto：oracle

基於OpenJDK，採起GPL+CE協議，作了一些安全性，性能和穩定性優化，而且修復了一些bug
支持linux，MAC OS還有Windows操做系統
長期支持Java 8而且至少到2023年
從2019年開始支持Java 11而且至少到2024
季度更新，而且伴隨一些緊急bug修復的更新

OpenJDK社區的FAQ部分曾經提到：「Amazon從2017年開始貢獻OpenJDK，而且計劃開始大量貢獻」。我猜Amazon會把他們在Corretto上面作的優化，合併到OpenJDK源碼中，即便沒有，Corretto也是開源的，早晚會有人蔘考並在OpenJDK源碼上進行修改。同時也說明，OpenJDK的更新也會及時被合併到Corretto中。app

準備遷移

1. 更新好開發環境以及編譯環境

各類經常使用工具，建議升級到以下版本之後：框架

IntelliJ IDEA: 2018.2
Eclipse: Photon 4.9RC2 with Java 11 plugin
Maven: 3.5.0
Maven compiler plugin: 3.8.0
surefire and failsafe: 2.22.0
Gradle: 5.0

對於以下工具，因爲已經再也不維護，須要替換成其餘工具：

FindBugs（靜態代碼bug發現）：用SpotBugs替換。
Cobertura（代碼測試覆蓋率）：用Jacoco替換

同時因爲在Java 9 以後，每六個月bytecode level會提高一次。若是你依賴的庫有處理字節碼相關的庫，應該注意下版本升級，例如：

對於直接操做字節碼的庫，若是你升級了JDK，那麼最好也跟着升級這些庫：ASM (7.0), Byte Buddy (1.9.0), cglib (3.2.8), or Javassist (3.23.1-GA).這些版本是OpenJDK11適用的版本
若是你使用的庫依賴了上面提到的操做字節碼的庫，那麼也須要注意下版本依賴，看依賴的操做字節碼的庫是否升級到了上面提到的版本。對於Spring，最好採用5.1之後的版本， Mockito則是2.20.0之後的版本

2. 引入JPMS後，相關的遷移工做

2.1. Java EE相關模塊默認不在Java包裏面了，相關的類須要增長額外依賴或者替換成其餘的類

若是你的項目中使用了這些類，那麼在編譯階段就會報錯，例如：

error: package javax.xml.bind does not exist
import javax.xml.bind.JAXBException;
                     ^

若是你是用JDK 8編譯成功，拿到JDK 11運行，就會報錯：

Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
    at monitor.Main.main(Main.java:27)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
    ... 1 more

如下是相關移除列表還有解決方案

JavaBeans Activation Framework (JAF) （javax.activation）變成了一個獨立的框架，maven依賴：

<dependency>
    <groupId>com.sun.activation</groupId>
    <artifactId>javax.activation</artifactId>
    <version>1.2.0</version>
</dependency>

CORBA(java.corba)在JEP 230已經不復存在了，在你的項目中若是遇到，證實你的項目太古老了。移除掉吧
JTA (java.transaction)變成了獨立依賴：

<dependency>
    <groupId>javax.transaction</groupId>
    <artifactId>javax.transaction-api</artifactId>
    <version>1.2</version>
</dependency>

JAXB和JAX-WS：

<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>2.2.8</version>
</dependency>
<dependency>
    <groupId>com.sun.xml.bind</groupId>
    <artifactId>jaxb-core</artifactId>
    <version>2.2.8</version>
</dependency>
<dependency>
    <groupId>com.sun.xml.bind</groupId>
    <artifactId>jaxb-impl</artifactId>
    <version>2.2.8</version>
</dependency>

<dependency>
    <groupId>com.sun.xml.ws</groupId>
    <artifactId>jaxws-ri</artifactId>
    <version>2.3.0</version>
    <type>pom</type>
</dependency>

Common Annotations:

<dependency>
    <groupId>javax.annotation</groupId>
    <artifactId>javax.annotation-api</artifactId>
    <version>1.3.1</version>
</dependency>

一個建議就是，在你的項目中若是沒有衝突，建議都加上這些依賴。

2.2. 模塊可見性致使的內部API不能調用的問題

這個在我另外一篇文章也說過：https://zhanghaoxin.blog.csdn.net/article/details/90514045

在Java9以後引入了模塊化的概念，是將類型和資源封裝在模塊中，並僅導出其餘模塊要訪問其公共類型的軟件包。若是模塊中的軟件包未導出或打開，則表示模塊的設計人員無心在模塊外部使用這些軟件包。這樣的包可能會被修改或甚至從模塊中刪除，無需任何通知。若是仍然使用這些軟件包經過使用命令行選項導出或打開它們，可能會面臨破壞應用程序的風險！

對於這種限制，在編譯階段，可能會有相似下面的報錯：

error: package com.sun.imageio.plugins.jpeg is not visible
import com.sun.imageio.plugins.jpeg.JPEG;
                              ^
  (package com.sun.imageio.plugins.jpeg is declared
  in module java.desktop, which does not export it)

若是是反射的調用，可能在運行階段有相似於以下的報警：

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by j9ms.internal.JPEG
    (file:...) to field com.sun.imageio.plugins.jpeg.JPEG.TEM
WARNING: Please consider reporting this
    to the maintainers of j9ms.internal.JPEG
WARNING: Use --illegal-access=warn to enable warnings
    of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
# here's the reflective access to the static field com.sun.imageio.plugins.jpeg.JPEG.TEM

對於這種錯誤，咱們最好是更換API，若是難以實現，則能夠經過添加編譯以及啓動參數解決。

咱們須要的參數是：

--add-exports選項:模塊聲明中的exports語句將模塊中的包導出到全部或其餘模塊，所以這些模塊可使用該包中的公共API。若是程序包未由模塊導出，則可使用-add-exports的命令行選項導出程序包:

--add-exports <source-module>/<package>=<target-module-list>

若是設置target-module-list爲ALL-UNNAMED，那麼全部Classpath下的module，均可以訪問source-module中的pakage包下的公共API

--add-opens選項: 模塊聲明中的opens語句使模塊裏面的包對其餘模塊開放，所以這些模塊能夠在運行期使用深層反射訪問該程序包中的全部成員類型。若是一個模塊的包未打開，可使用--add-opens命令行選項打開它。其語法以下：

--add-opens <source-module>/<package>=<target-module-list>

若是設置target-module-list爲ALL-UNNAMED，那麼全部Classpath下的module，均可以訪問source-module中的pakage包下的全部成員類型

對於編譯階段，也就是javac命令，咱們只須要添加--add-exports，對於上面的例子，就是：

javac --add-exports java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED

對於運行階段，也就是java命令，咱們最好把--add-exports和--add-open都加上，對於上面的例子，就是：

java --add-exports java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED --add-open java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED

這樣，在運行階段，首先不會有禁止訪問報錯，同時也不會有警告。

同時，爲了在運行期能找到全部須要添加的模塊和包，能夠經過添加--illegal-access=${value}來檢查。這個value能夠填寫：

permit: 將來可能會移除。僅在第一次反射調用內部api的時候報警
warn：每次次反射調用內部api的時候報警
debug：在warn的基礎上，加上堆棧輸出
deny: 拒絕全部非法反射訪問內部api

咱們能夠設置--illegal-access=deny來知道咱們須要添加的全部--add-export和--add-open包。

2.3 經過JDK11內置jdeps工具查找過時以及廢棄API以及對應的替換

這個也在我另外一篇文章提到過： https://zhanghaoxin.blog.csdn.net/article/details/100732605

jdeps --jdk-internals -R --class-path 'libs/*' $project

libs是你的全部依賴的目錄，$project是你的項目jar包，示例輸出：

...
JDK Internal API                         Suggested Replacement
----------------                         ---------------------
sun.misc.BASE64Encoder                   Use java.util.Base64 @since 1.8
sun.reflect.Reflection                   Use java.lang.StackWalker @since 9

在這裏簡單提一些在JDK11過時，可是JDK8使用的API：

sun.misc.Base64 (替換成 java.util.Base64)
com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel (替換成 javax.swing.plaf.nimbus.NimbusLookAndFeel)
java.util.LogManager, java.util.jar.Pack200.Packer類 Unpacker: addPropertyChangeListener 和 removePropertyChangeListener這兩個方法已經移除
java.lang.Runtime類: methods getLocalizedInputStream 和 getLocalizedOutputStream方法已經移除
SecurityManager的操做方法已經總體移除

2.4. ClassLoader變化帶來的URLClassLoader的變化

Java 8的ClassLoader流程：

bootstrap classloader加載rt.jar，jre/lib/endorsed
ext classloader加載jre/lib/ext
application classloader加載-cp指定的類

java9及以後的classloader流程：

bootstrap classloader加載lib/modules
ext classloader改名爲platform classloader，加載lib/modules
application classloader加載-cp，-mp指定的類

同時，咱們注意到，JDK9開始，AppClassLoader他爹再也不是 URLClassLoader

通常熱部署，插件部署，都會使用到AppClassLoader，例如Spring-Boot的熱部署，老版本的會報異常：

Exception in thread "main" java.lang.ClassCastException: java.base/jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to java.base/java.net.URLClassLoader
    at org.springframework.boot.devtools.restart.DefaultRestartInitializer.getUrls(DefaultRestartInitializer.java:93)
    at org.springframework.boot.devtools.restart.DefaultRestartInitializer.getInitialUrls(DefaultRestartInitializer.java:56)
    at org.springframework.boot.devtools.restart.Restarter.<init>(Restarter.java:140)
    at org.springframework.boot.devtools.restart.Restarter.initialize(Restarter.java:546)
    at org.springframework.boot.devtools.restart.RestartApplicationListener.onApplicationStartingEvent(RestartApplicationListener.java:67)
    at org.springframework.boot.devtools.restart.RestartApplicationListener.onApplicationEvent(RestartApplicationListener.java:45)
    at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172)
    at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165)
    at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139)
    at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:122)
    at org.springframework.boot.context.event.EventPublishingRunListener.starting(EventPublishingRunListener.java:69)
    at org.springframework.boot.SpringApplicationRunListeners.starting(SpringApplicationRunListeners.java:48)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:292)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1118)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1107)
    at com.asofdate.AsofdateMain.main(AsofdateMain.java:18)

這是主要是由於AppClassLoader再也不是URLClassLoader的子類致使的。

以前對於動態加載的類，咱們老是經過將這個類經過反射調用URLClassLoader加到classpath裏面進行加載。這麼加載在JDK11中已經沒法實現，而且這樣加載的類不能卸載。對於動態加載的類，咱們在OpenJDK11中只能自定義類加載器去加載，而不是經過獲取APPClassLoader去加載。同時，這麼作也有助於你隨時能將動態加載的類卸載，由於並無加載到APPClassLoader。

建議使用自定義的類加載器繼承SecureClassLoader去加載類： java.security.SecureClassLoader

最後，若是你想訪問classpath下的內容，你能夠讀取環境變量：

String pathSeparator = System
    .getProperty("path.separator");
String[] classPathEntries = System
    .getProperty("java.class.path")
    .split(pathSeparator);