相關推薦

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

距離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平台的核心優勢。

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

模式 舊的發布模式 新的發布模式
升級系列 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 工具變更
Bug 修復
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,但希望他們是經過思考判斷之後做出的決定。除了文章中提到的問題,還會有很多其他在升級前需要思考的因素,歡迎在評論中留下你的看法。

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

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

为您推荐

發佈留言

联系我们

联系我们

工作时间:周一至周五,9:00-17:30,节假日休息

返回顶部