1. 引言
听说过 Java EE 吗?那关于 Java 2 EE 、J2EE 或者现在的 Jakarta EE，你又是否有所耳闻呢?实际上，这些各异的术语描述的都是相同的东西：由 Java SE 扩展出的一系列企业规范。
在本篇短文中，我们将讲述 Java EE 的发展史。
2. 历史
在 Java 的***个版本中，Java 企业扩展还只是核心 JDK 的一部分(译者注：核心 JDK 通常指 Java SE) 。然而到了 1999 年，Java 企业扩展已经被剥离出 Java SE，成为了 Java 2 的一部分，这也意味着 J2EE，或者说Java 2 平台企业版(Java 2 Platform Enterprise Edition)的诞生。J2EE 这个称呼一直维持到2006年。
2006 年发布的 Java 5，J2EE 被重命名为 Java EE，或者说 Java 平台企业版(Java Platform Enterprise Edition)。这次改名后的称呼一直延续到 了 2017 年的 9 月。那年发生了一件重大的事，Oracle 决定将 Java EE 捐赠给 Eclipse 基金会(但 Java仍然属于 Oracle)。
3. 转变原因
事实上，因为 Oracle 拥有 “Java” 商标权。按照法律要求，Eclipse 基金会需要对 Java EE 进行更名。
经过社区的投票选择，Java EE 被更名为 Jakarta EE。从某种意义上来说，Java EE 依然叫 JEE。(译者注： 将 Java EE 首字母缩写也可简称为 JEE)。
不过这仍然是个正在进行的故事，还未完全尘埃落定。
举个例子，虽然 Oracle 开源了 Java 源代码，但却并未开源所有的文档。关于这个问题，因为涉及到一些法律事宜，导致开源一些文档(例如与 JMS、EJB相关的)非常棘手，至今仍有许多争议。
现在还无法得知新的 Eclipse 基金会文档是否能够参考原文档。
同样令人奇怪的是 Eclipse 基金会不能使用 javax 的命名空间来创建新的 Java 包，但是可以在现有包的下面创建新的类和子类。
转变阶段也意味着对 Jakarta EE 添加规范的新流程。为了更好地理解这一点，让我们快速看一下 Oracle 添加规范的流程以及 Eclipse 基金会相应做出的改变。
4.未来
在过去，为了将一个特性添加进 “EE”(译者注：原文作者为了避免 Jakarta EE 历史名字的混杂性，使用“EE”来代指全部的版本，下同)，我们需要 3 样东西 ：规范、参考实现与测试。社区里的任何人都可以提交这 3 样东西，之后执行委员会将会决定何时将它们整合进 Java 语言中。
为了更好地理解添加规范的旧流程，让我们进一步了解 JSRs、Glassfish 和 TCK是什么 ，以及它们是如何整合新特性的。
我们也将一睹在未来可以预期的事。
4.1 JCP 以及现在的 EFSP
在过去，产生EE 新特性的流程被称为 JCP(Java Community Process)。
Java SE 现在仍然采用 JCP。但是由于 EE 的所有权已经从 Oracle 移交至 Eclipse 基金会，EE 已经有了新的流程，这个流程是Eclipse 开发流程(https://www.eclipse.org/projects/dev_process)的扩展，与 Java SE 的流程互不干扰，我们称之为 EFSP(Eclipse Foundation Specification Process)。
尽管 JCP 与 EFSP 之间有一些大的差异，但大都围绕着“透明、公开、集体负责和供应商中立”这几条准则展开。例如，EFSP 的组织者设想的合作工作团体是供应商中立的，认证流程是自助服务的，组织的运作与管理是精英化的。
4.2 JSRs
在 JCP 中，为 EE 添加新特性的***步是创建一个 JSR(Java Specification Request)。JSR 有点类似于一个 EE 特性的接口。JCP 执行委员会会核准一个完整的 JSR，然后相应的 JSR 贡献者会编写代码，使其在社区内生效。
JSR-339 或者 JAX-RS 对于阐述上面的流程是一个好例子。JAX-RS 最初于 2011 年提出，在2012年被 JCP 批准，最终在 2013 年得以发布。
虽然在讨论规范时，社区可以随时加入进来，但时间表明，一个实现优先( implementation-first)的方式更利于创建能被广泛接受的特性与 API。所谓的实现优先，类似于JSR 310中的 java.time 和 Joda Time这个例子(译者注：JDK 1.8 之前 Java 关于时间的 API 很不如人意，使用广泛的是 Joda-Tme)。
因此，EFSP(Eclipse Foundation Specification Process)在其设定的目标中阐述了这个观点：“EFSP 将基于是否先进行了动手实验和编码，来判断其是否值得添加进规范中。
4.3 GlassFish
此外，JSR 作为 JCP 的一部分，需要一个参考实现。这有点类似于实现接口的类。对于那些想要创建自己的规范实现的群体，比如说兼容库的开发人员或者其他组织，参考实现都可以给予帮助。
对于 Java EE 特性，JCP 使用 Glassfish 作为参考实现。
虽然 Glassfish 的中心化简化了实现者的探索过程，但是这种中心化也要求更多的管理，并且倾向于偏袒某个供应商。
因此，EFSP 不要求参考实现，而只要求兼容的实现。简而言之，这种微妙的变化使得类似 Glassfish 之类的中心体系结构内的实现，不会被基金会无缘由地***。
4.4 TCK
***，JCP 要求 EE 特性需通过 TCK(Technology Compatibility Kit)的测试。
TCK 是一组验证特定 EE JSR 的测试。简而言之，为了遵循 Java EE，应用服务器需要实现所有 JSR， 并通过特定 TCK 上的所有测试。
与前述类似，Oracle虽然开源了TCK和EE jsr的源代码(译者注：但并没有开源相应的文档)。当然，未来所有的文档和 TCK 都将是开源的。
5. 总结
这些年来，Java EE 无疑前进了许多。很高兴看到它继续变化与变好。
前方之路充满坎坷，希望 Java 的转变能够平滑些。
作者 | Rodrigo Graciano
https://www.baeldung.com/java-enterprise-evolution
【本文为51CTO专栏作者“刘欣”的原创稿件，转载请通过作者微信公众号coderising获取授权】
