Java EE vs J2EE vs Jakarta EE – Java EE vs J2EE vs Jakarta EE

1. Introduction

1.绪论

Ever heard of Java EE? How about Java 2EE, J2EE, or now Jakarta EE? Actually, these are all different names for the same thing: a set of enterprise specifications that extend Java SE.

听说过Java EE吗？Java 2EE、J2EE，或者现在的Jakarta EE怎么样？实际上，这些都是同一件事的不同名称：一组扩展Java SE的企业规范。

In this short article, we’ll describe the evolution of Java EE.

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

2. History

2.历史

In the first version of Java, Java enterprise extensions were simply a part of the core JDK.

在Java的第一个版本中，Java企业扩展只是核心JDK的一部分。

Then, as part of Java 2 in 1999, these extensions were broken out of the standard binaries, and J2EE, or Java 2 Platform Enterprise Edition, was born. It would keep that name until 2006.

然后，作为 1999 年 Java 2 的一部分，这些扩展被从标准二进制文件中分离出来，J2EE，即Java 2 Platform Enterprise Edition，诞生了。它的这个名字将一直保留到2006年。

For Java 5 in 2006, J2EE was renamed to Java EE or Java Platform Enterprise Edition. That name would stick all the way to September 2017, when something major happened.

对于2006年的Java 5，J2EE被重新命名为Java EE或Java平台企业版。这个名字将一直坚持到2017年9月，这时发生了一件大事。

See, in September 2017, Oracle decided to give away the rights for Java EE to the Eclipse Foundation (the language is still owned by Oracle).

见，在2017年9月，Oracle决定将Java EE的权利交给Eclipse基金会（该语言仍由Oracle拥有）。

3. In Transition

3.在过渡期

Actually, the Eclipse Foundation legally had to rename Java EE. That’s because Oracle has the rights over the “Java” brand.

实际上，Eclipse基金会在法律上不得不重新命名Java EE。这是因为Oracle拥有 “Java “品牌的权利。

So to choose the new name, the community voted and picked: Jakarta EE. In a certain way, it’s still JEE.

所以为了选择新的名字，社区投票选出了。Jakarta EE。在某种程度上，它仍然是JEE。

*New name announced

This is still an evolving story, though, and the dust hasn’t completely settled.

不过，这仍然是一个不断发展的故事，尘埃还没有完全落定。

For example, while Oracle open-sourced the source code, they did not open-source all the documentation. There’s still a lot of discussion over this matter because of legal issues that make it tricky to open-source documentation related to, for example, JMS and EJB.

例如，虽然Oracle开源了源代码，但他们并没有开源所有的文档。由于法律问题，使得与JMS和EJB等相关的文档的开源变得很棘手，因此在这个问题上仍有很多的讨论。

It’s not clear yet if new Eclipse Foundation documentation will be able to refer to the originals.

目前还不清楚新的Eclipse基金会文档是否能够参考原件。

Also, curiously, the Eclipse Foundation can’t create any new Java packages using the javax namespace, but it can create new classes and subclasses under the existing ones.

另外，奇怪的是，Eclipse基金会不能使用javax命名空间创建任何新的Java包，但它可以在现有的包下创建新的类和子类。

The transition also means a new process for adding specifications to Jakarta EE. To understand it better, let’s take a look at what that process was like under Oracle and how it changes under the Eclipse Foundation.

这一转变也意味着向 Jakarta EE 添加规范的新流程。为了更好地理解这一点，让我们来看看在 Oracle 下该流程是怎样的，以及在 Eclipse 基金会下它是如何变化的。

4. The Future

4.未来

Historically, in order for a feature to make it into “EE”, we needed three things: a specification, a reference implementation, and tests. These three things could be provided by anyone in the community, and an Executive Committee would decide when these were ready to add to the language.

从历史上看，为了让一项功能进入 “EE”，我们需要三样东西。一个规范，一个参考实现，以及测试。这三样东西可以由社区中的任何人提供，而执行委员会将决定这些东西何时可以添加到语言中。

To better understand the past process, let’s take a closer look at what JSRs, Glassfish, and the TCK are and how they embodied new EE features.

为了更好地理解过去的过程，让我们仔细看看什么是JSRs、Glassfish和TCK，以及它们是如何体现新的EE特性的。

We’ll also get a glimpse of what to expect in the future.

我们还将领略到未来的期望。

4.1. The JCP and Now, the EFSP

4.1.JCP和现在的EFSP

In the past, the process by which a new EE feature was born was called the Java Community Process (JCP).

在过去，一个新的EE功能的诞生过程被称为Java社区进程（JCP）。

Java SE still uses the JCP today. But, since EE has changed its ownership, from Oracle to the Eclipse Foundation, we have a new and separate process for that. It’s the Eclipse Foundation Specification Process (EFSP) and it’s an extension of the Eclipse Development Process.

Java SE今天仍然使用JCP。但是，由于EE已经改变了它的所有权，从Oracle到Eclipse基金会，我们有一个新的和单独的流程。这就是Eclipse基金会规范流程（EFSP），它是Eclipse开发流程的延伸。

There are some important differences, though, mostly around “Transparency, Openness, Shared Burden and Vendor Neutrality”. The EFSP organizers, for example, envision collaborative working groups that are vendor-neutral, a certification process that is self-service, and an organization that operates and governs as a meritocracy.

但也有一些重要的区别，主要是围绕 “透明度、公开性、分担负担和供应商中立”。例如，EFSP的组织者设想了供应商中立的合作工作组，一个自我服务的认证过程，以及一个以任人唯贤方式运作和管理的组织。

4.2. JSRs

4.2 JSRs

In the JCP, the first step to adding a feature to EE was to create a JSR or Java Specification Request. The JSR was a bit like the interface for an EE feature. The JCP Executive Committee reviewed and approved a completed JSR, and then JSR contributors would code it up and make it available to the community.

在JCP中，为EE添加功能的第一步是创建一个JSR或Java规范请求。JSR有点像EE功能的接口。JCP执行委员会审查并批准了已完成的JSR，然后JSR贡献者将对其进行编码并向社区提供。

A good example of this was JSR-339  – or JAX-RS – which was originally proposed in 2011, approved by JCP in 2012 and finally released in 2013.

这方面的一个很好的例子是JSR-339 – 或JAX-RS – 它最初于2011年提出，于2012年被JCP批准，最终于2013年发布。

And while the community could always weigh in while a specification was under discussion, time showed that an implementation-first approach – like in the case of JSR 310, java.time, and Joda Time – tended to create more widely-accepted features and APIs.

虽然社区总是可以在讨论规范时提出意见，但时间表明，以实施为先的方法–如JSR 310、java.time和Joda Time的情况，往往会产生更广泛接受的功能和 API。

So, the EFSP reflects this code-first view in its stated goal: “EFSP will be based on hands-on experimenting and coding first, as a way to prove something is worthy of documenting in a specification.”

因此，EFSP在其声明的目标中反映了这种代码优先的观点：”EFSP将以实践实验为基础，首先进行编码，以此来证明一些东西是值得记录在规范中的。”

4.3. Glassfish

4.3.Glassfish

Then, as part of the JCP, a JSR needed a reference implementation. This is a bit like the class that implements the interface. A reference implementation helps developers of compatible libraries or other organizations that want to create their own implementation of the spec.

然后，作为JCP的一部分，一个JSR需要一个参考实现。这有点像实现接口的类。参考实现有助于兼容库的开发者或其他组织创建自己的规范实现。

For Java EE features, the JCP used Glassfish for its reference implementations.

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

And while this centralization on Glassfish simplified the discovery process for implementers, that centralization also required more governance and had a tendency to favor one vendor over another.

虽然Glassfish上的这种集中化简化了实施者的发现过程，但这种集中化也需要更多的管理，并有偏向一个供应商的趋势。

Hence, the EFSP doesn’t require a reference implementation, but instead only a compatible implementation. Simply put, this subtle change makes so that implementations inside of a central architecture, like Glassfish, won’t be inadvertently preferred by the foundation.

因此，EFSP并不要求参考实现，而只是要求一个兼容的实现。简单地说，这个微妙的变化使得中心架构中的实现，如Glassfish，不会无意中被基金会所青睐。

4.4. TCK

4.4.循环器(TCK)

Finally, the JCP required that EE features be tested through the Technology Compatibility Kit, or TCK.

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

The TCK was a suite of tests to validate a specific EE JSR. Simply put, in order to comply with Java EE, an application server needs to implement all of its JSRs and pass all the tests on the designated TCK.

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

Not much changes here. Oracle open-sourced the TCK as well as the EE JSRs. Of course, all future documents and the TCK will be open-source.

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

5. Conclusion

5.总结

Java EE has certainly evolved a lot during those years. It’s nice to see it continuing to change and improve.

在这些年里，Java EE确实有了很大的发展。很高兴看到它继续变化和改进。

There are many challenges ahead, so let’s hope for a smooth transition.

未来有许多挑战，让我们希望有一个平稳的过渡。