作者 | Rodrigo Graciano

編譯 | Panson

https://www.baeldung.com/java-enterprise-evolution

1. 引言

聽說過 Java EE 嗎？那關于 Java 2 EE 、J2EE 或者現(xiàn)在的 Jakarta EE，你又是否有所耳聞呢？實際上，這些各異的術語描述的都是相同的東西：由 Java SE 擴展出的一系列企業(yè)規(guī)范。

在本篇短文中，我們將講述 Java EE 的發(fā)展史。

?

2. 歷史

在 Java 的第一個版本中，Java 企業(yè)擴展還只是核心 JDK 的一部分（譯者注：核心 JDK 通常指 Java SE） 。然而到了 1999 年，Java 企業(yè)擴展已經被剝離出 Java SE，成為了 Java 2 的一部分，這也意味著 J2EE，或者說Java 2 平臺企業(yè)版（Java 2 Platform Enterprise Edition）的誕生。J2EE 這個稱呼一直維持到2006年。

2006 年發(fā)布的 Java 5，J2EE 被重命名為 Java EE，或者說 Java 平臺企業(yè)版（Java Platform Enterprise Edition）。這次改名后的稱呼一直延續(xù)到 了 2017 年的 9 月。那年發(fā)生了一件重大的事，Oracle 決定將 Java EE 捐贈給 Eclipse 基金會（但 Java仍然屬于 Oracle）。

?

3. 轉變原因

事實上，因為 Oracle 擁有 “Java” 商標權。按照法律要求，Eclipse 基金會需要對 Java EE 進行更名。

經過社區(qū)的投票選擇，Java EE 被更名為?Jakarta EE。從某種意義上來說，Java EE 依然叫 JEE。（譯者注： 將 Java EE 首字母縮寫也可簡稱為 JEE）。

不過這仍然是個正在進行的故事，還未完全塵埃落定。

舉個例子，雖然 Oracle 開源了 Java 源代碼，但卻并未開源所有的文檔。關于這個問題，因為涉及到一些法律事宜，導致開源一些文檔（例如與 JMS、EJB相關的）非常棘手，至今仍有許多爭議。

現(xiàn)在還無法得知新的 Eclipse 基金會文檔是否能夠參考原文檔。

同樣令人奇怪的是 Eclipse 基金會不能使用 javax 的命名空間來創(chuàng)建新的 Java 包，但是可以在現(xiàn)有包的下面創(chuàng)建新的類和子類。

轉變階段也意味著對 Jakarta EE 添加規(guī)范的新流程。為了更好地理解這一點，讓我們快速看一下 Oracle 添加規(guī)范的流程以及 Eclipse 基金會相應做出的改變。

?

4.未來

在過去，為了將一個特性添加進 “EE”（譯者注：原文作者為了避免 Jakarta EE 歷史名字的混雜性，使用“EE”來代指全部的版本，下同），我們需要 3 樣東西 ：規(guī)范、參考實現(xiàn)與測試。社區(qū)里的任何人都可以提交這 3 樣東西，之后執(zhí)行委員會將會決定何時將它們整合進 Java 語言中。

為了更好地理解添加規(guī)范的舊流程，讓我們進一步了解 JSRs、Glassfish 和 TCK是什么 ，以及它們是如何整合新特性的。

我們也將一睹在未來可以預期的事。

4.1 JCP 以及現(xiàn)在的 EFSP

在過去，產生EE 新特性的流程被稱為 JCP（Java Community Process）。

Java SE 現(xiàn)在仍然采用 JCP。但是由于 EE 的所有權已經從 Oracle 移交至 Eclipse 基金會，EE 已經有了新的流程，這個流程是Eclipse 開發(fā)流程(https://www.eclipse.org/projects/dev_process)的擴展，與 Java SE 的流程互不干擾，我們稱之為 EFSP（Eclipse Foundation Specification Process）。

盡管 JCP 與 EFSP 之間有一些大的差異，但大都圍繞著“透明、公開、集體負責和供應商中立”這幾條準則展開。例如，EFSP 的組織者設想的合作工作團體是供應商中立的，認證流程是自助服務的，組織的運作與管理是精英化的。

4.2 JSRs

在 JCP 中，為 EE 添加新特性的第一步是創(chuàng)建一個 JSR（Java Specification Request）。JSR 有點類似于一個 EE 特性的接口。JCP 執(zhí)行委員會會核準一個完整的 JSR，然后相應的 JSR 貢獻者會編寫代碼，使其在社區(qū)內生效。

JSR-339 或者 JAX-RS 對于闡述上面的流程是一個好例子。JAX-RS 最初于 2011 年提出，在2012年被 JCP 批準，最終在 2013 年得以發(fā)布。

雖然在討論規(guī)范時，社區(qū)可以隨時加入進來，但時間表明，一個實現(xiàn)優(yōu)先（ implementation-first）的方式更利于創(chuàng)建能被廣泛接受的特性與 API。所謂的實現(xiàn)優(yōu)先，類似于JSR 310中的 java.time 和 Joda Time這個例子（譯者注：JDK 1.8 之前 Java 關于時間的 API 很不如人意，使用廣泛的是 Joda-Tme）。

因此，EFSP（Eclipse Foundation Specification Process）在其設定的目標中闡述了這個觀點：“EFSP 將基于是否先進行了動手實驗和編碼，來判斷其是否值得添加進規(guī)范中。

4.3 GlassFish

此外，JSR 作為 JCP 的一部分，需要一個參考實現(xiàn)。這有點類似于實現(xiàn)接口的類。對于那些想要創(chuàng)建自己的規(guī)范實現(xiàn)的群體，比如說兼容庫的開發(fā)人員或者其他組織，參考實現(xiàn)都可以給予幫助。

對于 Java EE 特性，JCP 使用 Glassfish 作為參考實現(xiàn)。

雖然 Glassfish 的中心化簡化了實現(xiàn)者的探索過程，但是這種中心化也要求更多的管理，并且傾向于偏袒某個供應商。

因此，EFSP 不要求參考實現(xiàn)，而只要求兼容的實現(xiàn)。簡而言之，這種微妙的變化使得類似 Glassfish 之類的中心體系結構內的實現(xiàn)，不會被基金會無緣由地首選。

4.4 TCK

最后，JCP 要求 EE 特性需通過 TCK（Technology Compatibility Kit）的測試。

TCK 是一組驗證特定 EE JSR 的測試。簡而言之，為了遵循 Java EE，應用服務器需要實現(xiàn)所有 JSR， 并通過特定 TCK 上的所有測試。

與前述類似，Oracle雖然開源了TCK和EE jsr的源代碼（譯者注：但并沒有開源相應的文檔）。當然，未來所有的文檔和 TCK 都將是開源的。

?

5. 總結

這些年來，Java EE 無疑前進了許多。很高興看到它繼續(xù)變化與變好。

前方之路充滿坎坷，希望 Java 的轉變能夠平滑些。

總結

以上是生活随笔為你收集整理的小白科普：Java EE vs J2EE vs Jakarta EE的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。