有没有听说过Java EE？Java 2EE，J2EE或现在的Jakarta EE怎么样？实际上，这些都是同一个东西的不同名称：一组扩展Java SE的企业规范。

在这篇简短的文章中，我们将描述Java EE的演变。

历史回顾

在Java的第一个版本中，Java企业扩展只是核心JDK的一部分。然后，作为1999年Java 2的一部分，这些扩展从标准库包中脱离出来，  J2EE或Java 2平台企业版诞生了，这个名称维持到2006年。2006年的Java 5，J2EE被重命名为Java EE或Java Platform Enterprise Edition。这个名字一直持续到2017年9月，当时发生了重大事件。请参阅，2017年9月，  Oracle决定将Java EE的权利授予Eclipse Foundation(该语言仍由Oracle拥有)。

转型期

实际上，Eclipse Foundation 必须重命名Java EE。这是因为Oracle拥有“Java”品牌的权利。因此，为了选择新名称，社区投票选出：Jakarta EE。在某种程度上，它仍然是JEE。

尽管如此，这仍然是一个不断发展的故事，尘埃尚未完全解决。例如，虽然Oracle开源了源代码，但他们没有开源所有文档。关于这个问题仍然有很多讨论，因为法律问题使得与例如JMS和EJB相关的开源文档变得棘手。

目前尚不清楚新的Eclipse Foundation文档是否能够引用原件。

另外，奇怪的是，Eclipse Foundation不能使用javax命名空间创建任何新的Java包，但它可以在现有的类下创建新的类和子类。切换还意味着向Jakarta EE 添加规范的新流程。为了更好地理解它，让我们来看看Oracle下的流程是什么样的，以及它在Eclipse Foundation下的变化。

未来

从历史上看，为了使特性成为“EE”，我们需要三件事：规范，参考实现和测试。 这三件事可以由社区中的任何人提供，执行委员会将决定何时可以添加到语言中。为了更好地理解过去的流程，让我们仔细看看  JSR，Glassfish和TCK是什么以及它们如何体现新的EE功能。

JCP和现在，EFSP

过去，新EE功能诞生的过程称为Java Community Process(JCP)。

Java SE今天仍然使用JCP。但是，由于EE已经改变了它的所有权，从Oracle到Eclipse Foundation，我们有一个新的独立流程。它是Eclipse Foundation Specification Process(EFSP)，是Eclipse Development Process的扩展  。

但是，存在一些重要的差异，主要是“透明度，开放性，共享负担和供应商中立性”。例如，EFSP组织者设想了与供应商无关的协作工作组，一个自助服务的认证流程，以及一个以精英管理运营和管理的组织。

JSR

在JCP中，向EE添加功能的第一步是创建JSR或Java规范请求。JSR有点像 EE功能的接口。JCP执行委员会审核并批准了已完成的JSR，然后JSR贡献者将对其进行编码并将其提供给社区。一个很好的例子是  JSR-339   - 或JAX-RS--最初于2011年提出，2012年由JCP批准，最终于2013年发布。虽然社区总能权衡，同时规范正在讨论之中，一半采取实现优先的批准策略，如JSR 310，java.time，  Joda Time 表明：倾向于创更多能被广泛接受的功能和API 。

因此，EFSP在其既定目标中反映了这种“代码实现优先”的观点：“EFSP将首先基于动手实验和编码，只有这样才能证明其内容值得在规范中进行登记。”

Glassfish

作为JCP的一部分，JSR需要一个具体的参考实现。这有点像实现接口的类。参考实现必须兼容以往库包或其他组织的开发人员创建自己的规范实现。

对于Java EE功能，JCP使用Glassfish作为其参考实现。

虽然Glassfish的这种集中化简化了实施者的发现过程，但这种集中化还需要更多的治理，并倾向于支持一个供应商而不是另一个供应商。

因此，EFSP不需要参考实现，而只需要  兼容的 实现。简而言之，这种微妙的变化使得基础设施内部的实现(如Glassfish)不会被基金会无意中所偏爱。

TCK

最后，JCP要求通过技术兼容性工具包或TCK测试EE功能  。

TCK是一套验证特定EE JSR的测试。简单地说，为了符合Java EE，应用服务器需要实现其所有JSR并在指定的TCK上传递所有测试。

这里没什么变化。Oracle开源TCK以及EE JSR。当然，所有未来的文件和TCK都将是开源的。

Java EE在这些年里确实发展了很多。很高兴看到它继续改变和改进。未来还有很多挑战，所以我们希望顺利过渡。