重命名后JavaEE有何新变化？ 英文原文：JakartaEE:Noturningback JakartaEE正在为EnterpriseJava开辟一条新路。在本文中，CesarSaavedra解释了为什么JakartaEE是企业Java的一股清流。 首先，作为一名拥有30年IT经验的老手，我做过开发人员、服务顾问、技术销售人员和技术营销人员。我见证了IT和软件市场从开源软件和Java开始的演变。对于长期沉浸在IT中的我们来说，无论出现什么新技术，似乎总是在试图解决我们自计算机诞生以来就一直在努力解决的问题（封装性、可重用性、易用性、分布式系统、数据管理等）。 我还记得在90年代参加我的第一个Java研讨会（由SunMicrosystems组织）。除了朗朗上口的“一次编写，随处运行”的口头禅外，作为一名开发人员，我对这种门语言感到敬畏，因为我不再需要担心分配和释放内存，而且可移植性得到保证。这两个功能将为我节省大量的开发时间！然后是JavaEnterpriseEdition（JPE->J2EE->JavaEE），它提供了一组用于开发企业级功能的API，许多企业发现这些API对于开发生产应用程序很有用，这些应用程序仍在全球运行。Java仍然是当今最先进的语言之一。 JakartaEE简介 然而，我们现在生活在一个不同的时代，云计算、容器、微服务、迷你服务、API管理、无服务器计算、响应式系统已经成为成功的必要条件，作为新经济要求在开发、交付和维护应用程序时具有超敏捷性。已经有大量用于微服务和云计算的运行时和框架。 例如，Node.js在微服务开发中变得非常流行，而JavaEE不再是唯一基于JVM的框架，Spring和EclipseVert.x是另外两个需要考虑的框架。使用单一编程语言开发应用程序的日子已经一去不复返了。 事实上，在最近的红帽客户调查中，87%的受访者表示他们正在使用或考虑使用多种技术来开发微服务。同样，在2018年Eclipse基金会雅加达EE开发人员调查中，68%的受访者表示，他们超过60%的应用程序是使用多种语言实现的。 JavaEE仍然对全球的企业和开发人员具有价值和生产力，但作为标准，JavaEE已经落后于云计算、容器和微服务。正因为如此，社区在2016年“克服困难”决定创建MicroProfile——一个社区驱动的开源规范，现在与Eclipse基金会共存——专注于为微服务优化企业Java。许多反对者多年来一直宣称“JavaEE已死”，虽然这在某种程度上是正确的，但最近作为Eclipse项目JakartaEE出现的JavaEE正在带来一些重大变化。 JakartaEE作为云原生Java的新家，已经从Oracle手中接过JavaEE，并计划在2018年第三季度和2018年第四季度发布符合JavaEE8规范的Glassfish5.1基于新的认证流程发布了符合JakartaEE8规范的Glassfish5.1，以确保过渡的完整性。 2018年的其他交付成果包括JavaEE8规范、RI、TCK、现有和新规范的流程、兼容性流程等。目前，Eclipse基金会正在组织JakartaEE子项目。下一步，JakartaEE将在云计算、容器、微服务、无服务器计算和响应式技术方面开启快速演进过程。JakartaEE2018年计划：从充满活力的开发人员社区获得支持加强对微服务架构的支持转向云原生Java更快的创新：变得更加敏捷提供生产质量的参考实现 此外，JakartaEE将通过以下方式实现生态系统现代化：使用一个新的开放规范流程来取代JCP新的治理结构一种更开放的贡献方式 EclipseMicroProfile 与EclipseMicroProfile的紧密集成。在撰写本文时，EclipseMicroProfile1.4和2.0已经包含配置、容错、指标、JWT传播、开放API、开放跟踪、健康检查和Rest客户端的企业级规范，并且可以与JavaEE7或Java结合EE8使用。 由于MicroProfile和JakartaEE之间的高度协同，后续的云平台可以通过采用这些MicroProfile规范快速走上正轨。两个社区之间已经进行了讨论，以改进两个开源项目的一致性。现在判断结果会是什么还为时过早，但可能会出现以下情况：EclipseMicroProfile在EE4J下移动，由JakartaEE工作组管理。EclipseMicroProfile在EE4J下移动并继续使用其自己的治理流程。保持现状，作为Eclipse基金会的一个独立项目，每个项目都有自己的治理流程。 无论如何，EclipseMicroProfile都可以继续作为一个快节奏的孵化项目，新的想法不断涌现，并交给开发人员进行试验和改进。这些MicroProfileAPI已经在市场上使用，并根据社区和用户反馈进行了强化，因此JakartaEE可以将它们视为候选者。正因为如此，我认为在两年后（甚至更短），JakartaEE将包含微服务架构、容器、云计算、API管理、无服务器计算、反应式系统和服务网格的完整规范。 开发者为何爱上JakartaEE 支持云原生Java并不是JakartaEE***的目标。全世界成千上万的企业仍然信任JavaEE来处理他们的生产工作负载。在最近的红帽客户调查中，红帽中间件客户使用或考虑将JavaEE用于微服务的三大原因是： 此外，在2018年Eclipse基金会雅加达EE开发人员调查中，受访者表示他们的组织选择JavaEE的最重要原因是：稳定性规范开发人员可用性多个供应商提供兼容性实现 很明显，市场仍然青睐社区驱动的开源规范，因为开源规范让企业在选择实现方面有更多的自由，他们可以充分利用开发人员的专业知识，或者更容易在就业市场上找到具备这些技能的人才。 此外，有许多组织并不真正需要微服务。并非每个企业都必须是Uber或Netflix。在大多数情况下，JavaEE工作负载将在未来几年继续在生产环境中运行。有些公司，由于业务性质的原因，无法在生产中进行“实时测试”，比如金丝雀发布、蓝绿部署、A/B测试等，你的电影不做也没关系播放或您的出租车没有出现，但是当涉及将心脏运送给移植患者或飞机导航系统中的错误时，没有机会重来。 但是，采用容器、云计算、CI/CD、DevOps等敏捷方法/框架进行开发有明显的好处，因为所有这些都可以实现数字化。事实上，根据2016年贝恩公司和红帽数字化转型调查，数字化成熟的公司获得市场份额的可能性是普通公司的八倍。 JakartaEE的未来 因此，随着JakartaEE的发展，它还必须找到方法来保留组织信任的JavaEE功能。这在JakartaEE中会是什么样子？以下是社区目前正在讨论的一些注意事项：现有的完整配置可以标记为“稳定”或“推荐可选”，以便社区可以专注于与云计算、容器、微服务、互联网/网络规模、高度分布式的集成——相关的新功能。摆脱配置的概念，采用可组合的API模型，这是一种应用程序组装的方法（类似于WildFlySwarm，最近更名为Thorntail），通过它创建的应用程序只需要JakartaAPI，不需要其他任何东西。JakartaEE中需要保留一个最小的核心配置，其他配置可以在此基础上构建。需要定义多少配置？可能需要核心（Servlet或CDI或两者）、Web、微服务、完整和自定义。提供旧版完整配置（用于向后兼容）和新的完整配置，其中包括云原生企业Java规范（无旧版配置）和一些其他子配置。集成或包含服务网格。以上选项的组合。 很明显，JakartaEE需要在未来几年内保留JavaEE的关键特性，以便为现有JavaEE客户提供通往新JakartaEE的途径。同样，现有的JavaEE企业将能够逐步利用JakartaEE的新云原生功能，同时仍然使用关键的JavaEE功能。他们还应该有足够的时间将标记为“推荐可选”的JavaEE功能迁移到新的JakartaEE功能。 JakartaEE与微服务 说到Java微服务，就不能不提到已经火爆的SpringBoot。SpringBoot和Spring也是基于Java的，是JakartaEE的竞争对手。SpringBoot采用了Dropwizard和Pivotal的“fatjar”概念。SpringBoot背后的公司Pivotal正在推广“云原生”这个词，这个词最初是由Netflix创造的，现在在市场上被广泛使用。 虽然云原生应用在容器和微服务流行之前就已经存在，但这些都极大地影响和改变了云原生应用的发展。fatjars的概念正在被分层容器镜像所取代，事实证明，分层容器镜像更高效，可以加快云原生应用程序的交付。 在运行时方面，想要采用微服务架构的组织大多转向Node.js和SpringBoot（以及MicroProfile，根据2018年EclipseFoundationJakartaEEDeveloper的数据，采用率达到了15%）。虽然一些应用服务器非常适合微服务架构，但JavaEE不仅速度慢而且太耗资源的说法在市场上流传开来，一棍子打死了所有的应用服务器。 但这些说法已经站不住脚了。JakartaEE将拥有云原生企业级Java功能，为组织提供微服务和云原生应用程序开发的另一种选择。 有更多的框架和语言可供选择，这对于现在习惯于使用正确的工具完成正确的任务的开发人员来说非常棒。Pivotal是Spring的所有者，与IBM、RedHat、Oracle、Microsoft、Fujitsu、SAP、Lightbend等一起参与了JakartaEE工作组。那么，这对Spring的未来意味着什么呢？JakartaEE和Spring将如何发展？这里有很多可能性：通过协作，Pivotal正在将JakartaEE发展成为一个社区驱动的、云原生的、企业级的Java规范，将功能整合到一个规范中。JakartaEE未能占领市场，Spring成为云原生企业Java的最佳选择。JakartaEE获得了市场份额并取代了Spring。JakartaEE与Spring共存。 结论 不管两年后会发生什么，我认为开发商已经赢了。因为所有这些供应商、用户组、开源社区成员和公司都聚集在JakartaEE上，并联手开发云原生企业Java规范，这将使每个人受益。 JakartaEE是企业Java的新曙光。
