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

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

\\

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

\\

我还记得90年代第一次参加Java研讨会（由Sun Microsystems组织）。除了吸引人的“一次编写，到处运行”口号，作为一名开发人员，我充满对这种门语言的敬畏之情，因为我不再需要为分配和释放内存而操心，并且可以保证可移植性。这两项功能将为我节省大量的开发时间！然后是Java企业版（JPE -\u0026gt; J2EE -\u0026gt; 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的最重要原因是：

\\

1. 稳定性\\t
2. 规范\\t
3. 开发人员的可用性\\t
4. 多个供应商提供兼容性的实现\

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

\\

此外，有很多组织其实不需要微服务。不是每个企业都要成为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将如何发展？这里有很多可能性：

\\

• 通过协作，Pivotal将Jakarta EE发展成为社区驱动的云原生企业级Java规范，从而将功能汇集到单个规范中。\

• Jakarta EE未能占领市场，Spring成为云原生企业Java的唯一可选项。\

• Jakarta EE取得市场份额并取代Spring。\

• Jakarta EE与Spring共存。\

结论

\\

无论两年后会发生什么，我认为开发人员已经取得了胜利。因为所有这些供应商、用户组、开源社区成员和公司齐聚Jakarta EE，并联手开发云原生企业Java规范，这将为所有人都带来好处。

\\

Jakarta EE是企业版Java的新曙光。

\\

查看英文原文：https://jaxenter.com/jakarta-ee-no-turning-back-146824.html