java最新技术趋势(深入分析java未来趋势)-众学网

译者 | 平川策划 | 丁晓昀

我们探讨 Java 最主要的趋势，如 Java 新版本的采用，以及 Jakarta EE、Quarkus、Micronaut、Helidon、MicroProfile 和 MicroStream 等框架的演变。

本报告主要有两个目标：

帮助技术负责人做出中长期的技术投资决策。

帮助个体开发者选择将其宝贵的时间和资源投入到何种技能的学习和发展中去。这是我们发布的第三份 Java 趋势报告。不过，我们从 2006 年开始就在内部跟踪 Java 和 JVM 的趋势，因此，我们实际上已经对这个话题做了充分的报道。

为了把握当前和未来的趋势，我们采用了 Geoffrey Moore 在其同名著作中首倡的 “跨越鸿沟 “技术成功心理模型。我们试图识别出那些符合 Moore 所说的早期市场的想法，即 “客户群是由技术爱好者和有远见的人组成的，他们希望在机会或迫在眉睫的问题上占得先机”。

和 2020、2019 年的 Java 发展趋势报告一样，下面是 2021 年我们内部使用的主题图谱：

作为背景信息，下面是 2020 年我们内部使用的主题图谱。

除了 Innovators 领域的一些新技术之外，其他值得注意的变化包括：将 Spring（及其相关项目）、Jakarta EE 和 Scala 的版本定义为不同类别。我们决定采用这种方法是为了避免将成熟度和采用情况不同的技术归入一个类别。

计划于 2022 年底发布的 Spring Framework 6 和 Spring Boot 3 将经历一次大幅修改以采用模块化，并将需要 JDK 17 和 Jakarta EE 9。最近，Spring Framework 6 的第一个里程碑版本已经提供了预览。

Spring Native 是 2021 年初推出的一个新工具，可以将当前用 Java 或 Kotlin 编写的 Spring Boot 应用程序转换为 GraalVM 原生镜像，该项目目前处于早期开发阶段。

2021 年初发布的 Scala 3 进行了大幅修改，增加了许多新特性、新语法和备受期待的新 Dotty 编译器，该编译器已经开发了好几年了。

2021 年 4 月，微软推出了 Microsoft Build of OpenJDK，即他们自己的 OpenJDK 下游发行版，进一步增加了对 Java 编程语言的投入。

AdoptOpenJDK 加入了 Eclipse 基金会，并立即改名为 Adoptium。向 Adoptium 的过渡工作包括建立一个 Eclipse 工作组，并将 AdoptOpenJDK 拆分为 Adoptium 顶级项目下的多个子项目：Eclipse AQAvit、Eclipse Temurin 和 Eclipse Temurin Compliance。

Monica Beckwith，微软高级首席工程师和 Java Champion。

Ana Maria Mihalceanu，红帽开发大使和 Java Champion。

Reza Rahman，微软 Azure 首席 Java 项目主管。

Simon Ritter，Azul 公司副首席技术官和 Java Champion。

我们认为，这可以为我们在内部主题图谱上对某些技术的建议定位提供更多的背景信息。

JDK 17

Beckwith：通过“JEP 403：JDK 内件强封装”，Java 现在成了更有力的 OOP 原则执行者。通过一个平台无关的 Vector API 进行向量计算。语言增强，如 Records，JVM 改进，如 Valhalla 项目，消除了许多冗长的内容，并进一步拥抱了不变性的概念，为性能优化提供了可能。

Mihalceanu：2021 年，无论是 Java 的 LTS 版本，还是非 LTS 版本，都给 Java 开发者带来了惊喜。Java 17 的发布证实，预览功能中的许多功能现在已正式可用，并将长期可用。它也增加了将一些仍在 Java 8 上运行的项目迁移到更新版本的紧迫感。Java 17 是长期支持版本，它实现了 NullPointerExceptions 这个 Java 开发人员长期以来的梦想。

Rahman：一如既往，Java 生态系统的各个部分都保持着活力。这证明了 Java 的根本优势。我认为，Java SE 17 特别受欢迎，尤其是像 Records 这样的功能。像 WildFly、Payara 和 Open Liberty 这样的运行系统正在采用 Java SE 17。虽然一些开发者已经采用了 Java SE 11，但 Java SE 8 仍然非常有黏性。Java SE 17 有可能最终改变这种状况。

Ritter：JDK 17 的发布意义重大。这意味着所有的 OpenJDK 发行版都有了一个新的长期支持（LTS）版本。对于那些为了尽可能保持稳定和安全而不希望每六个月升级 Java 版本的人来说，这是一个重要的发行版。我们看到，一些小的语言特性往平台添加的速度比以往任何时候都更快，我喜欢这种方式。这要归功于六个月的发布节奏，这也使得孵化器模块和预览功能都更实用。

关于 JVM 在云环境中的运行机制方面也有一些有趣的进展，如 OpenJDK 中有一个名为检查点协调恢复（CRaC）的新项目。像 Records 这样的特性是开发新代码的上佳选择。

Evans：Java 17 LTS 发布，已具备能力部署使用了记录和密封类型的代码，还有用于监控 JVM 组的 JFR 流。在可观察性领域走向标准化——特别是 OpenTelemetry。对于 Java 静态部署的含义（“静态 Java”）出现了早期共识的迹象。我还认为，Panama 将是一个超出人们预期的项目。

OpenJDK 的下游发行版

Costlow：现在，JDK 有太多没什么差异的发行版。微软有一个，Eclipse 有 Adoptium with Temurin，Oracle 也有他们自己的，还有 Azul、AWS Corretto、Red Hat、Liberica、SAP Machine 等 OpenJDK 构建。我看到，这些东西在快速增加，但很难把它们都搞清楚。Snyk 的调查似乎与我看到的使用情况一致。鉴于它们都是兼容的，我希望市场能提供一个随机装置，我只要告诉它 ”给我个 OpenJDK“就行，让新晋 Java 开发人员不用再为选择哪个 JDK 发行版而苦恼。

Eclipse 的品牌建设尤其令人困惑：Adoptium 是 Eclipse 里面的一个小组，而 Eclipse 也是一个小组。你在使用 Temurin，它是 OpenJDK。想象一下，假如你在自己学习 Java，碰到这样一句话：”Eclipse Temurin 是 Adoptium 提供的 OpenJDK 发行版的名字”。品牌名称还是越少越好。

Janssen：来自 Bellsoft 的 Liberica 实际上提供了相当有趣的产品，这使得他们不同于其他 JDK 供应商。例如，有一个完整的 JDK 仍然包含 JavaFX。我只知道 ojdkbuild 提供了一个类似的构建。除此之外，他们还有其他多个 JDK 和 JRE 的变种。

Azul 支持非 LTS 版本，并会在更长的时间内提供小版本更新。部分供应商还提供 Docker 镜像等。所以差异还是有一些的，但最终用户很难对它们进行比较，并正确选择使用哪一个。

Java EE/Jakarta EE

Rahman：从 Java EE 到 Jakarta EE 的过渡是我们这个领域最大最重要的技术转换之一。Jakarta EE 9.x 的推出为这一转换打下了坚实的基础。很高兴看到 Jakarta EE 10 正朝着 2022 年初发布的方向前进。看起来，Jakarta EE 大使贡献指南中的许多项目都正在实现过程中，这可以填补一些长期存在的空白。我认为，Java EE 的长期用户可以松一口气了。

我也非常高兴地看到，Jakarta EE 9.x 发展势头不错。大多数运行时已经完成了从 javax 到 jakarta 命名空间的过渡，包括 Tomcat 和 Jetty。Spring Framework 6 正致力于同时采用 Java SE 17 和 Jakarta EE 9。同样，MicroProfile 5 也正在向 Jakarta EE 过渡。根据 2021 年 Jakarta EE 开发者调查，相当多的开发者已经过渡到 jakarta 命名空间或正在计划这样做。

Jakarta EE 10 Core Profile 正在为实现 Quarkus 和 Helidon 的完全兼容铺路，MicroProfile Config API 正在向新的 Jakarta 配置规范过渡，MicroProfile Context Propagation 也在发生着同样的变化。MicroProfile REST 客户端和 JWT Propagation 也可能会发生同样的情况。

Redlich：随着 Jakarta EE 9 的发布，工具供应商可以支持新的 jakarta 包命名空间，开发团队可以测试应用程序向新命名空间的迁移，而运行时供应商可以测试并提供选项和能力，为迁移和兼容 Jakarta EE 8 提供支持。Jakarta EE 9 也被认为是一个创新的基础，有助于推动 Jakarta EE 10 及后续版本的新特性。

GraalVM/Spring Native

Mihalceanu：构建本地可执行文件是另一个经常被标记为 “最需要 “的话题，因为围绕容器化应用程序更小更快的竞赛仍在继续。

Rahman：看到 Spring Native 不断取得进展也是非常好的。

Costlow：我很高兴地看到，原生应用程序的角色已逐步成型，但令人失望的是，缺少一个具体的规范或工作组。情况似乎会变成这样，“你得到了 GraalVM 碰巧提供的东西”，但它的行为有时与标准 JDK 不同——相似但不相同。

Janssen：Spring Native 携启动速度快和内存占用率低的优势与所有 GraalVM 及其他框架展开了竞争。

Silz：一旦 Spring Boot 支持 GraalVM 的本地编译，快速而小巧的原生 Java 程序将成为主流。这将使得 Java 在无服务器解决方案方面更具竞争力，并可能有助于其在微服务领域的采用。我说 “可能 “，是因为我认为，到今天为止，对于长期运行的进程，JVM JIT 的吞吐量 / 性能仍然优于 GraalVM。无论怎样，这都会得到大量媒体的报道，并使 Java 在整体上更具竞争力。

ARM64/Windows on ARM

Beckwith：ARM64 现在是商用硬件。因此，为在 ARM64 上部署而优化过的 Java 开发工具包和 Java 运行时环境已经越来越主流。

Silz：Java 16 支持 Windows on ARM。但我认为，只有 Java 17 和 ARM on macOS 一起才能打开方便之门。我相信，大约有四分之一的 Java 开发者使用 Mac。而到 2022 年底，他们只能购买带有 ARM 的 Mac。我预计这也将推动 Windows/Linux on ARM 变得更好。

Jakarta EE 与 MicroProfile结盟 == Java 云原生

Redlich：MicroProfile 和 Jakarta EE 工作组是 Eclipse 基金会下两项互补的计划，他们合作成立了 Java 云原生（CN4J），一个定义 Jakarta EE 和 MicroProfile 定位和合作关系的联盟，包括品牌和云原生技术。

Rahman：看到 Quarkus 在 Java EE 和 Spring 开发者中取得了应有的进展，真是让人惊喜。我也很高兴能够看到 Jakarta EE 和 MicroProfile 最终结盟。

JavaFX/Gluon

采用模块化

Silz：我认为 JPMS 试图解决三个问题：应用服务器的类加载困境；更好地组织 JDK 和所有的 Java 应用；减少部署 / 运行时的 JVM 内存占用。

然而，至少在 JPMS 多次推迟后终于推出时，这些问题都已经有了足够好的解决方案：用于类加载的 OSGI；用于 Java 程序结构的领域驱动设计 / 清洁架构 /Modulith/ArchUnit 测试；以及用于减少 JVM 内存占用的提前编译。

尽管我们可能有少数数据点不可靠，但它们都显示，Java 8 及更早版本的使用量要大于等于 Java 11 及更新版本的使用量。我认为，这部分是因为模块使 Java 9 获得了“很难从 Java 8 升级上去”的名声，这点也为 Mark Reinhold 所承认。这是 JPMS 所带来的一个意想不到的后果。这意味着至少有一半的 Java 开发者无法利用过去 7 年中 Java 取得的进步，因为他们被困在了 Java 8 上。

在模块上投入了 7 年多，其间的机会成本意味着许多其他的 Java 改进要么被搁置，要么只出现在 Java 10 及后续版本中。变量关键字 var、新的 switch 语法和 Java Record 减少了 Java 中许多臭名昭著的样板代码。如果这些都出现在 Java 9 中，而不是 Java 模块中，我想 Java 现在的情况会更好，因为它为开发者带来了更高的生产力。

自去年至今有什么变化？

Beckwith：得益于现有垃圾收集器的改进，许多架构师和开发人员已经控制了 GC（垃圾收集）的暂停时间。还有许多人通过将工作负载迁移到低延迟、自适应的 GC 来控制尾部延迟。

Evans：在市场份额方面，Java 11 已经基本上与 Java 8 持平。容器取得突破性进展，现在已成为大多数 Java 应用程序的部署方式。Quarkus 日趋成熟，并吸引了大量的新粉丝。

Redlich：Eclipse 基金会下成立了多个工作组：MicroProfile、OSGi 和 Adoptium（以前称为 AdoptOpenJDK）。MicroProfile 工作组和 Jakarta EE 工作组在 Cloud Native for Java（CN4J）联盟倡议上展开了合作。

微软创建了自己的 OpenJDK 下游发行版——Microsoft Build of OpenJDK，并加入 Java Community Process，进一步增加了对 Java 的投入。

Java 社区怎么说？

Beckwith：Switch 语句的模式匹配、本地镜像、云原生 -JVM 和加速器上的 JVM、Loom 和 Graal 项目。

Mihalceanu：升级换代。由于 Java 语言的发展，框架特性也随之蓬勃发展。根据我的经验，编写干净、安全的代码直接取决于团队的共享方式。现在，得益于一些框架的内置功能，可以通过持续测试以及少量的本地配置来尽量减少开发或修复代码的时间。

Evans: Java 17、Loom、Quarkus。

有什么意料之外的令人兴奋的新东西？

Beckwith：我预料到了 Java 生态系统的丰富性和 Java 开发工具包产品不同 JDK 供应商的偏好。不过，大家的参与度以及对发布节奏加速的认同，还是让人感到惊喜。

Mihalceanu：我喜欢 Java 的地方在于，每个版本都会调整语言和开发体验。诸如 java.time.format.DateTimeFormatter 和 DateTimeFormatterBuilder 类中新引入的 period-of-day 日期格式、switch 模式匹配或者 java.util.stream.Stream 接口中的 toList() 默认方法等增强功能，都有助于开发人员编写更干净、更容易阅读的代码。

Ritter：纵观 Java 平台，没有什么是我们没有想到的，这是件好事。现在，新特性都是使用 JEP 来定义它们要做的事情，我们有一个清晰的路线图，从中可以看到未来若干年内将包含在 Java 中的东西。也就是说，开发者可以放心，不会有影响向后兼容性的大变化，至少不会在没有足够的时间来评估和讨论的情况下。

Redlich：MicroStream 成立，这是一家 Java 持久化公司。虽然他们的历史可以追溯到 2013 年，但该公司是 2019 年正式成立的。从那时起，他们开源了 MicroStream，并在今年早些时候发布了 MicroStream 5.0。MicroStream 已经与 Helidon 集成，而且刚刚发布了 6.0 版本。

Silz：在停滞多年后，VS Code 正在颠覆 Java IDE 领域的局面。它是个新颖的东西：一个跨平台、跨语言的 IDE，它速度快，有非常不错的插件，并且广受用户喜爱！你可能觉得这听起来像 “20 年前的 Eclipse IDE”，没错。

VS Code 最近增强了它的 Java 功能。我希望它能成为最好的免费 Java IDE。我认为 Eclipse 意识到了这种威胁，并创建了一个工作组来协同防御。我不确定 IntelliJ 会受到多大的影响。

使用 VS Code 进行 Java 开发有一个令人兴奋的副作用，就是你可以很轻松地用非 JVM 语言进行开发。我认为你在 Eclipse 中根本无法做到这一点，或者只能在一定程度上做到。你可以使用 JetBrains 的 “所有产品包 “来开发非 JVM 语言，但是你必须启动不同的 IDE，它们不共享设置、插件或键盘快捷键。

Java 社区

Mihalceanu：我在大学时就开始了我的 Java 之旅，了解到 Java 支持面向对象编程，包括设计模式和最佳编码实践。作为一名专业人士，我很高兴地看到，随着时间的推移，这门语言也吸收了其他范式：函数式、反应式，在不失去可读性的前提下提供了更多的实现选项。如何在这些模式之间做出选择？间或对应用程序进行性能分析，发现瓶颈，并改进实现逻辑。

此外，没有人就不可能有进步。Java 社区是一个庞大的、充满活力的、热情洋溢的社区，无论是实际存在的社区，还是虚拟社区，目的都是一样的：分享知识，提高自己，成功地解决问题。

请注意，贡献者的观点仅仅道出了这个故事的一部分。Java 生态系统的不同部分和地区可能有不同的经验。您可以将我们这份 2021 年 Java 发展趋势报告视为一个辩论的起点，而不是一份权威性的声明，并欢迎大家对行业的发展方向进行公开讨论。

https://www.infoq.com/articles/java-jvm-trends-2021/