1. 引言

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

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

2. 歷史

在 Java 的***個版本中，Java 企業(yè)擴展還只是核心 JDK 的一部分(譯者注：核心 JDK 通常指 Java SE) 。然而到了 1999 年，Java 企業(yè)擴展已經(jīng)被剝離出 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. 轉(zhuǎn)變原因

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

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

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

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

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

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

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

4.未來

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

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

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

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

在過去，產(chǎn)生EE 新特性的流程被稱為 JCP(Java Community Process)。

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

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

4.2 JSRs

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

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 關(guān)于時間的 API 很不如人意，使用廣泛的是 Joda-Tme)。

因此，EFSP(Eclipse Foundation Specification Process)在其設(shè)定的目標中闡述了這個觀點：“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)者的探索過程，但是這種中心化也要求更多的管理，并且傾向于偏袒某個供應(yīng)商。

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

4.4 TCK

***，JCP 要求 EE 特性需通過 TCK(Technology Compatibility Kit)的測試。

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

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

5. 總結(jié)

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

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

作者 | Rodrigo Graciano

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

【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號coderising獲取授權(quán)】

戳這里，看該作者更多好文