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 的轉變能夠平滑些。
獲取更多JAVA乾貨內容，轉發+關注。私信我“資料”即可獲取。
閱讀更多 java高級架構 的文章
