- 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 平臺的核心優勢。
下面深入瞭解一下為什麼在舊的發佈模式下，升級版本不會導致任何問題。先看一下新舊發佈模式之間的差異：
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，但希望他們是經過思考判斷之後做出的決定。除了文章中提到的問題，還會有很多其他在升級前需要思考的因素，歡迎在評論中留下你的看法。
來源：http://t.cn/ExoBhyC
搜索微信號（ID：芋道源碼），可以獲得各種 Java 源碼解析。
並且，回覆【書籍】後，可以領取筆者推薦的各種 Java 從入門到架構的書籍。
來吧，騷年~
閱讀更多 Java芋道源碼 的文章
