小白科普：Java EE vs J2EE vs Jakarta EE

栏目: Java · 发布时间: 5年前

内容简介：听说过 Java EE 吗?那关于 Java 2 EE 、J2EE 或者现在的 Jakarta EE，你又是否有所耳闻呢?实际上，这些各异的术语描述的都是相同的东西：由 Java SE 扩展出的一系列企业规范。在本篇短文中，我们将讲述 Java EE 的发展史。在 Java 的第一个版本中，Java 企业扩展还只是核心 JDK 的一部分(译者注：核心 JDK 通常指 Java SE) 。然而到了 1999 年，Java 企业扩展已经被剥离出 Java SE，成为了 Java 2 的一部分，这也意味着 J2E

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)。

小白科普：Java EE vs J2EE vs Jakarta EE

不过这仍然是个正在进行的故事，还未完全尘埃落定。

举个例子，虽然 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 将基于是否先进行了动手实验和编码，来判断其是否值得添加进规范中。