我該用 Java 12 仍是堅持 Java 11？

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

640?wx_fmt=png

本文經受權轉自開源中國

距離 Java 11 的正式發佈已過去一個多月，而 Java 12 也正在趕來的路上。根據此前開源中國發起的一項關於開發者使用的 Java 版本的調查（https://www.oschina.net/quest...）顯示，Java 8 仍然是開發者的主流選擇，而 Java 11 是 Java 8 以後的首個 LTS 版本，因此有很多開發者表示會選擇升級至 Java 11。按照 Java 的發佈計劃，Java 12 將於明年 3 月推出，那麼問題來了，咱們是應該採用 Java 12，仍是堅持使用 Java 11 呢？

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

640?wx_fmt=png

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 平臺的核心優點。

下面深刻了解一下爲何在舊的發佈模式下，升級版本不會致使任何問題。先看一下新舊發佈模式之間的差別：

640?wx_fmt=png

640?wx_fmt=png

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 方法，並在下一個版本中刪除它。

640?wx_fmt=png

採用新版本 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 博客

640?wx_fmt=png

總結

相信確定已經有開發團隊採用了新版本的 Java，但但願他們是通過思考判斷以後作出的決定。除了文章中提到的問題，還會有不少其餘在升級前須要思考的因素，歡迎在評論中留下你的見解。