|
|
距离 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 会快速更新吗？如果不是，你会怎么做？
|
+10
|
[复制链接]
|Archiver|手机版|深圳市光明谷科技有限公司|光明谷商城|Sunshine Silicon Corpporation
( 粤ICP备14060730号 ) 
|Sitemap
发表于 2018-11-5 23:22:46
收藏
转播
分享
淘帖
支持
反对
楼主