我應該採用 Java 12 還是堅持使用 Java 11？

Java · 發表 2018-11-05 08:22:12

摘要：編譯自https://blog.joda.org/2018/10/adopt-java-12-or-stick-on-11.html 原文作者 Stephen Colebourne 是一名 Java 開發者，同時也是一位知名的 Java 博主...

編譯自ofollow,noindex">https://blog.joda.org/2018/10/adopt-java-12-or-stick-on-11.html

原文作者 Stephen Colebourne 是一名 Java 開發者，同時也是一位知名的 Java 博主和會議演講者。

距離 Java 11 的正式釋出已過去一個多月，而 Java 12 也正在趕來的路上。根據此前開源中國發起的一項關於開發者使用的 Java 版本的調查，Java 8 仍然是開發者的主流選擇，而 Java 11 是 Java 8 之後的首個 LTS 版本，所以有不少開發者表示會選擇升級至 Java 11。按照 Java 的釋出計劃，Java 12 將於明年 3 月推出。那麼問題來了，我們是應該採用 Java 12，還是堅持使用 Java 11 呢？

可能你會覺得這是一個無關緊要的問題，但對於那些需要在 JVM 中使用 Java 的開發者，或是比較看重 Java 新特性的開發者，這是一項十分重要的決策。這篇文章將和大家就這個問題進行相關的分析。

Java 釋出計劃

現在每六個月就會發佈一個新的 Java 版本，所以儘管 Java 11 才釋出不久，但距離 Java 12 的釋出也就剩下不到五個月的時間。作為釋出計劃的一部分，某些版本會被指定為長期支援版本(LTS)，它們會獲得四年或更長時間的技術支援和安全補丁更新。所以這些版本通常會被稱為“主要版本” —— 不是因為它們擁有更多的功能特性，而是因為它們具有長期的技術支援。

預計 Java 11 的更新補丁(11.0.1, 11.0.2, 11.0.3 等)將比 Java 8 的補丁(8u20, 8u40, 8u60)更小更簡單。因為 Java 11 的更新將更加集中在安全補丁上，不會像 Java 8 的更新那樣帶來內部的功能增強。Oracle 希望將 Java 12, 13, 14 等這些版本當做是小更新版本，類比成 Java 8 的話，即是 Java 11u20, 11u40。

Oracle 高階員工一再認為像 8u20 和 8u40 這樣的更新常常會帶來破壞性的變更，但本文作者表示這不是自己的經歷，他記得的唯一有破壞性的變化是為 Javadoc添加了 --allow-script-in-comments ，但它也不是 Java 的核心部分。因此，他從不擔心升級到最新版本帶來的影響 —— 因為這是 Java 平臺的核心優勢。

下面深入瞭解一下為什麼在舊的釋出模式下，升級版本不會導致任何問題。先看一下新舊釋出模式之間的差異：

Bug 修復
模式	舊的釋出模式		新的釋出模式
升級系列	Java 主要版本	Java 更新版本	Java 版本系列	Java 補丁版本
頻率	每隔3年左右	每6個月一次	每6個月一次	每3個月一次
版本	6 -> 7 -> 8	8 -> 8u20 -> 8u40	11 -> 12 -> 13	11 -> 11.0.1 -> 11.0.2
語言變化	✘	✘
JVM 變化	✘	✘
主要的功能增強	✘	✘
新增的 classes/methods	✘	✘
移除的 classes/methods	✘	✘	✘
新的棄用	✘	✘
內部功能增強	✘
JDK 工具變更	✘
Security 補丁

Oracle 的官方觀點認為：與 Java 7->8->9 相比，Java 9->10->11 的升級和 8->8u20->8u40 更相似。

表格清楚地顯示新模式下的 Java 版本釋出都會包含許多變更，包括語言變更和 JVM 變更，這兩者都會對 IDE、位元組碼庫和框架產生重大影響。此外，不僅會新增其他 API，還會有 API 被刪除（這在 Java 8 之前沒有發生過）。

Oracle 的觀點是，因為每個版本僅在前一個版本釋出後的6個月推出，所以不會有太多新的“東西”，因此升級並不困難。雖然如此，但這不是重點。重要的是升級是否有可能會破壞程式碼。很明顯，從 11 -> 12 -> 13 開始，程式碼遭受破壞的可能性要大於 8 -> 8u20 -> 8u40。

11 -> 12 -> 13 與 8u20 -> 8u40 等這樣的更新主要區別在於對位元組碼版本的更改以及對規範的更改，對位元組碼版本的更改往往特別具有破壞性，大多數框架都大量使用與每個位元組碼版本密切相關的 ASM 或 ByteBuddy 等庫。而 8u20 -> 8u40 仍然使用相同的 Java SE 規範，具有所有相同的類和方法，不同於從 Java 12 移動到 13。

除此之外，Oracle 的另一個宣告也十分值得我們關注。宣告透露出的訊息是，如果堅持使用 Java 11 並計劃在下一個 LTS 版本(即 Java 17)釋出時再進行升級，開發者可能會發現自己的專案程式碼無法通過編譯。所以請記住，Java 新的開發規則現在宣告可以在一個版本中棄用某個 API 方法，並在下一個版本中刪除它。

採用新版本 Java 的注意事項

在本節中，將概述在採用新版本 Java 之前必須考慮的一些注意事項/風險。

被新版本系列“繫結”

如果採用了 Java 12 並使用新的語言特性或新的 API，這意味著實際上你已將專案繫結到 Java 的新版本系列。接下來你必須採用 Java 13, 14, 15, 16 和 17，並且必須在下一個版本釋出後的一個月內採用每個新版本 。

使用了新版本，每個版本的使用壽命為六個月，並且在釋出後僅七個月就過時了。這是因為每個版本只有在六個月內提供安全補丁，釋出後1個月的第一個補丁和釋出後4個月的第二個補丁。7個月後，下一組安全補丁會發布，但舊版本不能獲取更新。

因此，你要判斷自身的開發流程是否允許升級 Java 版本，時間視窗方面會不會太狹窄？

升級的“絆腳石”

實際使用中有很多阻止我們升級 Java 的因素，下面列出一些常見的：

開發資源不足：你的團隊可能會非常忙碌或規模太小，你能保證兩年後從 Java 15 升級到 16 的開發時間嗎？
構建工具和 IDE：你使用的 IDE 是否會在釋出當天支援每個新版本？Maven? Gradle 呢? 如果不是，你有後備計劃嗎？請記住，你只有1個月的時間來完成升級、測試並將其釋出到生產環境中。此外還包括 Checkstyle，JaCoCo，PMD，SpotBugs 等等其他工具。
依賴關係：你的依賴關係是否都準備好用於每個新版本？請記住，它不僅僅是直接依賴項，而是技術堆疊中的所有內容。位元組碼操作庫尤其受到影響，例如 ByteBuddy 和 ASM。
框架：這是另一種依賴，但是一個大而重要的依賴。在一個月的狹窄時間視窗內，Spring 會每六個月釋出一個新版本嗎？ Jakarta EE(以前的 Java EE)會嗎？如果它們不這樣做會怎麼樣？

雲 / 託管 / 部署

你是否可以控制程式碼在生產環境中的執行位置和方式？例如，如果你在 AWS Lambda 中執行程式碼，則無法控制。AWS Lambda 沒有采用 Java 9或10，甚至沒有采用 Java 11。所以除非 AWS 提供公共保證以支援每個新的 Java 版本，否則根本無法採用 Java 12。

如何託管你的 CI 系統？Jenkins, Travis, Circle, Shippable, GitLab 會快速更新嗎？如果不是，你會怎麼做？

對未來的預測

如果已經閱讀了上面的列表，並且你的程式碼和流程可以應對。這十分好，但更重要的是要明白，你也在限制未來進行改變的能力。例如，你的程式碼可能今天不在 AWS Lambda 上執行，但未來三年呢？

為採用新版本進行規劃

如果正在考慮採用新版本的 Java，建議你準備一份現在所依賴的所有內容的清單，或者可能在未來3年內會依賴的。你需要保證該列表中的所有內容都能正常工作，並與新版本一起升級，或者如果該依賴項不再更新，請制定好計劃。作者提供了他的清單：

Amazon AWS
Eclipse
IntelliJ
Travis CI
Shippable CI
Maven
Maven plugins (compile, jar, source, javadoc, etc)
Checkstyle, 以及相關的 IDE 外掛和 maven 外掛
JaCoCo, 以及相關的 IDE 外掛和 maven 外掛
PMD 和相關的 maven 外掛
SpotBugs 和相關的 maven 外掛
OSGi bundle metadata tool
Bytecode 工具(Byte buddy / ASM etc)
超過 100 個 jar 包依賴項

說了這麼多，作者當然不是鼓勵大家不進行升級，新語言特性帶來的好處以及效能增強會讓開發者受益，但升級背後的風險也應該考慮進去。

其他第三方產商的宣告

Spring 框架已經在視訊中表達了對 Java 12 的策略。關鍵部分是：

“Java 8 和 11 作為 LTS 版本會持續獲得我們的正式支援，對於過渡版本，我們也會盡最大努力支援。如果你升級到 Java 11，我們非常願意和你合作，但它們不會獲得正式的生產環境支援。因為長期支援版本才是我們關注的重心，對於 Java 12 及更高版本我們會盡最大的努力。”

作為典型軟體供應商的一個例子，Liferay 宣告如下：

Liferay 已決定不會對 JDK 的每個主要版本進行認證。我們將選擇遵循 Oracle 的主導並僅認證標記為 LTS 的版本。——Liferay部落格

總結

相信肯定已經有開發團隊採用了新版本的 Java，但希望他們是經過思考判斷之後做出的決定。除了文章中提到的問題，還會有很多其他在升級前需要思考的因素，歡迎在評論中留下你的看法。