你到底該用 Java 12 還是堅持 Java 11？

搭上火箭也追不上的 Java 更新速度，不少程序員們大呼，我可不可以堅持使用 Java 8？！但是對於已使用到 LTS 版本的 Java 11 開發者，是否還有必要往上升級？

距離 Java 11 的正式發佈已過去一個多月，而 Java 12 也正在趕來的路上。根據此前開源中國發起的一項關於開發者使用的 Java 版本的調查（https://www.oschina.net/question/2918182_2287320）顯示，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 平臺的核心優勢。

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

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江湖 的文章

關鍵字: Java 編程語言 IDE