清欢渡

该用 Java 12 还是坚持 Java 11?

电脑版发表于:2018/12/12 11:41

搭上火箭也追不上的 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 8 和 11 作为 LTS 版本会持续获得我们的正式支持,对于过渡版本,我们也会尽最大努力支持。如果你升级到 Java 11,我们非常愿意和你合作,但它们不会获得正式的生产环境支持。因为长期支持版本才是我们关注的重心,对于 Java 12 及更高版本我们会尽最大的努力。”

  • 作为典型软件供应商的一个例子,Liferay 声明如下:

  • Liferay 已决定不会对 JDK 的每个主要版本进行认证。我们将选择遵循 Oracle 的主导并仅认证标记为 LTS 的版本。—— Liferay 博客

总结

相信肯定已经有开发团队采用了新版本的 Java,但希望他们是经过思考判断之后做出的决定。除了文章中提到的问题,还会有很多其他在升级前需要思考的因素,欢迎在评论中留下你的看法。


             

关于TNBLOG
TNBLOG,技术分享。技术交流:群号677373950
ICP备案 :渝ICP备18016597号-1
App store Android
精彩评论
{{item.replyName}}
{{item.content}}
{{item.time}}
{{subpj.replyName}}
@{{subpj.beReplyName}}{{subpj.content}}
{{subpj.time}}
猜你喜欢