转载

改名之后的Java EE，现在有什么新进展？

英文原文： Jakarta EE: No turning back

Jakarta EE 正在为企业版 Java 开辟新的道路。在这篇文章中，Cesar Saavedra 将解释为什么说 Jakarta EE 为企业版 Java 带来了新鲜的空气。

首先，作为一名具有 30 年经验的 IT 老兵，我曾经是开发者、服务顾问、技术销售人员和技术营销人员。从出现开源软件和 Java 开始，我就一路看着 IT 和软件市场的发展。对于我们这些长期浸淫 IT 的人来说，无论出现什么样的新技术，它们似乎总是试图解决自计算机诞生以来我们就一直在尝试解决的问题（封装、可重用性、可用性、分布式系统、数据管理等等）。

我还记得 90 年代第一次参加 Java 研讨会（由 Sun Microsystems 组织）。除了吸引人的“一次编写，到处运行”口号，作为一名开发人员，我充满对这种门语言的敬畏之情，因为我不再需要为分配和释放内存而操心，并且可以保证可移植性。这两项功能将为我节省大量的开发时间！然后是 Java 企业版（JPE -> J2EE -> Java EE），它提供了一组 API 用于开发企业级功能，很多企业发现这些功能对于开发生产应用程序来说非常有用，这些应用程序到现在仍然在全球范围内运行。Java 仍然是当今最顶级的语言之一。

Jakarta EE 简介

然而，我们现在生活在一个不同的时代，云计算、容器、微服务、迷你服务、API 管理、无服务器计算、反应式系统已经成为在数字经济中获得竞争力并取得成功的必要条件，因为新经济时代要求在开发、交付和维护应用程序方面具备超敏捷性。现在已经有大量适用于微服务和云计算的运行时和框架。

例如，Node.js 在微服务开发中变得非常流行，而 Java EE 不再是唯一基于 JVM 的框架，Spring 和 Eclipse Vert.x 是另外两个可以考虑的框架。使用单一的编程语言来开发应用程序的日子已经一去不复返。

事实上，在 Red Hat 最近的一次客户调查中，87％的受访者表示，他们正在使用或者考虑使用多种技术来开发微服务。同样的，在 2018 年 Eclipse 基金会 Jakarta EE 开发者调查中，68％的受访者表示，他们有超过 60％的应用程序在实现过程中使用了多种语言。

对于全球的企业和开发人员来说，Java EE 仍然具有其价值和生产力，但是作为一个标准，Java EE 已经落后于云计算、容器和微服务。正因为如此，社区决定在 2016 年“不畏艰险”地创建了 MicroProfile——这是一个社区驱动的开源规范，现在与 Eclipse 基金共存——专注于为微服务而优化企业版 Java。很多反对者多年来一直宣称“Java EE 已经死亡”，尽管这在某种程度上说的是事实，但最近作为 Eclipse 项目 Jakarta EE 出现的 Java EE 正带来一些重大的变化。

Jakarta EE 作为云原生 Java 的新家，从甲骨文手中接过 Java EE，计划在 2018 年第三季度发布符合 Java EE 8 规范的的 Glassfish 5.1，并基于新的认证流程在 2018 年第四季度发布符合 Jakarta EE 8 规范的 Glassfish 5.1，以此来确保交接的完整性。

其他可在 2018 年交付的包括 Java EE 8 规范、RI、TCK、现有规范和新规范的流程、兼容性过程等。目前，Eclipse 基金会正在组织 Jakarta EE 子项目。下一步，Jakarta EE 将开始启动在云计算、容器、微服务、无服务器计算和反应式技术方面的快速演化进程。Jakarta EE 在 2018 年计划：

得到充满活力的开发者社区的支持
增强对微服务架构的支持
转到云原生 Java
更快的创新：变得更加敏捷
提供具备生产级质量的参考实现

此外，Jakarta EE 将通过以下方式让生态系统变得更加现代化：

使用新的开放规范流程取代 JCP
新的治理结构
更开放的贡献方式

Eclipse MicroProfile

加快 Jakarta EE 发展的一个关键因素是它与 Eclipse MicroProfile 的紧密结合。在撰写本文时，Eclipse MicroProfile 1.4 和 2.0 已经包含了 Configuration、Fault Tolerance、Metrics、JWT propagation、Open API、Open Tracing、Health Check 和 Rest Client 的企业级规范，并可以与 Java EE 7 或 Java EE 8 结合使用。

由于 MicroProfile 和 Jakarta EE 之间的高度协同作用，后续的云平台可以通过采用这些 MicroProfile 规范快速走上轨道。两个社区已经就提升这两个开源项目的一致性展开了讨论。现在说结果如何还为时尚早，不过有可能出现以下这些情况：

Eclipse MicroProfile 移至 EE4J 下，由 Jakarta EE 工作组负责治理。
Eclipse MicroProfile 移至 EE4J 下，并继续使用自己的治理流程。
保持现状，作为 Eclipse 基金会的一个单独项目，每个项目都有自己的治理流程。

无论如何，Eclipse MicroProfile 可以继续作为一个快节奏的孵化项目，新想法不断出现，并交由开发人员去实验和改进。这些 MicroProfile API 已经被用在市场中，并根据社区和用户的反馈进行加固，所以 Jakarta EE 可以将它们作为候选。正因为如此，我认为，在两年时间内（甚至更早），Jakarta EE 将包含针对微服务架构、容器、云计算、API 管理、无服务器计算、反应式系统和服务网格的完整规范。

为什么开发人员会爱上 Jakarta EE

支持云原生 Java 并不是 Jakarta EE 唯一的目标。世界上有成千上万家企业仍然信任使用 Java EE 来处理他们的生产负载。在 Red Hat 最近的客户调查中，Red Hat Middleware 客户使用或考虑将 Java EE 用于微服务的三大原因是：

Java EE 是一种标准
不需要重新培训员工
我们信任 Java EE，因为它已经很成熟，而且是企业级的

此外，在 2018 年 Eclipse 基金会 Jakarta EE 开发者调查中，受访者表示，他们所在组织选择 Java EE 的最重要原因是：

稳定性
规范
开发人员的可用性
多个供应商提供兼容性的实现

很显然，市场仍然青睐社区驱动的开源规范，因为开源规范让企业在选择实现时更加自由，他们可以充分利用开发人员的专业知识或在就业市场中更容易找到具备这些种技能的人才。

此外，有很多组织其实不需要微服务。不是每个企业都要成为 Uber 或 Netflix。在大多数情况下，Java EE 工作负载将在未来几年继续运行在生产环境中。有一部分公司，由于业务性质的关系，不能在生产中进行“实时测试”，例如金丝雀发布、蓝绿部署、A/B 测试等。如果你的电影无法播放或者你的出租车没有出现，那都没有关系，但对于运送给移植病人的心脏或飞机导航系统的 bug，根本没有重来一次的机会。

不过，采用敏捷方法 / 框架进行开发有明显的好处，例如容器、云计算、CI/CD、DevOps 等，因为所有这些都支持数字化。事实上，根据 2016 年贝恩公司和 Red Hat 数字化转型的调查，数字化成熟度较高的公司获得市场份额的可能性是普通公司的 8 倍。

Jakarta EE 的未来

因此，在 Jakarta EE 的发展过程中，它还必须想方设法保留受组织信任的 Java EE 功能。这在 Jakarta EE 中将会是什么样子？以下是社区目前正在讨论的一些注意事项：

可以将现有的完整配置标记为“稳定”或“建议可选项”，这样社区就可以专注于与云计算、容器、微服务、互联网 /Web 规模、高度分布相关的新功能。
摆脱配置的概念，并采用可组合 API 模型，也就是一种应用程序组装方法（类似于 WildFly Swarm，最近更名为 Thorntail），通过它创建的应用程序只需要 Jakarta API，而不需要其他东西。
需要在 Jakarta EE 中保留最小化的核心配置，可以基于这个核心配置构建其他配置。
需要定义多少个配置？可能需要核心（Servlet 或 CDI 或两者）、Web、微服务、完整和自定义。
提供一个遗留的完整配置（为了向后兼容）和一个新的完整配置，新配置包括云原生企业 Java 规范（无遗留配置），以及少数其他子配置。
集成或包含服务网格。
上述选项的组合。

很显然，Jakarta EE 需要在未来几年内保留 Java EE 的关键功能，以便为现有的 Java EE 客户提供一条通向新 Jakarta EE 的途径。同样，现有的 Java EE 企业将能够逐步利用 Jakarta EE 的新云原生功能，同时仍然可以使用 Java EE 的关键功能。他们还应该有足够的时间将标记为“建议可选项”的 Java EE 功能迁移到新的 Jakarta EE 功能。

Jakarta EE 和微服务

说到 Java 微服务，不得不提及 Spring Boot，它已经变得非常流行。Spring Boot 和 Spring 也是基于 Java，是 Jakarta EE 的竞争对手。Spring Boot 采用了 Dropwizard 和 Pivotal 的“fat jar”概念。Pivotal 是 Spring Boot 背后的公司，正在推动“云原生”一词，这个词最初是由 Netflix 发明的，目前已经在市场上得到广泛使用。

尽管在容器和微服务变得流行之前就已存在云原生应用程序，但这些极大地影响和改变了云原生应用程序开发。fat jar 的概念正在被分层容器镜像所取代，容器镜像被证明更加有效，并加快了云原生应用程序的交付。

在运行时方面，想要采用微服务架构的组织大多朝着 Node.js 和 Spring Boot（以及 MicroProfile，根据 2018 年的 Eclipse 基金会 Jakarta EE 开发者调查结果，从项目建立第 1 年的采用率就达到了 15％）的方向发展。虽然一些应用程序服务器非常适合微服务架构，但 Java EE 不仅慢而且太耗资源的说法已经在市场上传播开，一棒子打死了所有应用程序服务器。

但这些说法现在不再有任何立足之地了。Jakarta EE 将具备云原生企业级 Java 功能，组织因此有了微服务和云原生应用程序开发的另一种选择。

有更多的框架和语言可选择对于开发人员来说是件好事，他们现在已经习惯了使用正确的工具来完成正确的任务。Spring 的所有者 Pivotal 与 IBM、Red Hat、甲骨文、微软、富士通、SAP、Lightbend 等公司一起参与了 Jakarta EE 工作组。那么，这对 Spring 的未来意味着什么呢？Jakarta EE 和 Spring 将如何发展？这里有很多可能性：