JEE、J2EE與Jakarta等概念解釋

歷史回顧
在Java的第一個版本中，Java企業擴充套件只是核心JDK的一部分。然後，作為1999年Java 2的一部分，這些擴充套件從標準庫包中脫離出來，  J2EE或Java 2平臺企業版誕生了，這個名稱維持到2006年。2006年的Java 5，J2EE被重新命名為Java EE或Java Platform Enterprise Edition。這個名字一直持續到2017年9月，當時發生了重大事件。請參閱，2017年9月，  Oracle決定將Java EE的權利授予Eclipse Foundation（該語言仍由Oracle擁有）。

轉型期
實際上，Eclipse Foundation 必須重新命名Java EE。這是因為Oracle擁有“Java”品牌的權利。因此，為了選擇新名稱，社群投票選出：Jakarta EE。在某種程度上，它仍然是JEE。
儘管如此，這仍然是一個不斷髮展的故事，塵埃尚未完全解決。例如，雖然Oracle開源了原始碼，但他們沒有開源所有文件。關於這個問題仍然有很多討論，因為法律問題使得與例如JMS和EJB相關的開源文件變得棘手。
目前尚不清楚新的Eclipse Foundation文件是否能夠引用原件。
另外，奇怪的是，Eclipse Foundation不能使用javax名稱空間建立任何新的Java包，但它可以在現有的類下建立新的類和子類。切換還意味著向Jakarta EE 新增規範的新流程。為了更好地理解它，讓我們來看看Oracle下的流程是什麼樣的，以及它在Eclipse Foundation下的變化。

未來
從歷史上看，為了使特性成為“EE”，我們需要三件事：規範，參考實現和測試。 這三件事可以由社群中的任何人提供，執行委員會將決定何時可以新增到語言中。為了更好地理解過去的流程，讓我們仔細看看  JSR，Glassfish和TCK是什麼以及它們如何體現新的EE功能。

JCP和現在，EFSP
過去，新EE功能誕生的過程稱為Java Community Process（JCP）。
Java SE今天仍然使用JCP。但是，由於EE已經改變了它的所有權，從Oracle到Eclipse Foundation，我們有一個新的獨立流程。它是Eclipse Foundation Specification Process（EFSP），是Eclipse Development Process的擴充套件  。
但是，存在一些重要的差異，主要是“透明度，開放性，共享負擔和供應商中立性”。例如，EFSP組織者設想了與供應商無關的協作工作組，一個自助服務的認證流程，以及一個以精英管理運營和管理的組織。

JSR
在JCP中，向EE新增功能的第一步是建立JSR或Java規範請求。JSR有點像 EE功能的介面。JCP執行委員會稽核並批准了已完成的JSR，然後JSR貢獻者將對其進行編碼並將其提供給社群。一個很好的例子是  JSR-339   - 或JAX-RS--最初於2011年提出，2012年由JCP批准，最終於2013年釋出。雖然社群總能權衡，同時規範正在討論之中，一半採取實現優先的批准策略，如JSR 310，java.time，  Joda Time 表明：傾向於創更多能被廣泛接受的功能和API 。
因此，EFSP在其既定目標中反映了這種“程式碼實現優先”的觀點：“EFSP將首先基於動手實驗和編碼，只有這樣才能證明其內容值得在規範中進行登記。”

Glassfish
作為JCP的一部分，JSR需要一個具體的參考實現。這有點像實現介面的類。參考實現必須相容以往庫包或其他組織的開發人員建立自己的規範實現。

對於Java EE功能，JCP使用Glassfish作為其參考實現。
雖然Glassfish的這種集中化簡化了實施者的發現過程，但這種集中化還需要更多的治理，並傾向於支援一個供應商而不是另一個供應商。
因此，EFSP不需要參考實現，而只需要  相容的 實現。簡而言之，這種微妙的變化使得基礎設施內部的實現（如Glassfish）不會被基金會無意中所偏愛。

TCK
最後，JCP要求透過技術相容性工具包或TCK測試EE功能  。
TCK是一套驗證特定EE JSR的測試。簡單地說，為了符合Java EE，應用伺服器需要實現其所有JSR並在指定的TCK上傳遞所有測試。
這裡沒什麼變化。Oracle開源TCK以及EE JSR。當然，所有未來的檔案和TCK都將是開源的。

Java EE在這些年裡確實發展了很多。很高興看到它繼續改變和改進。未來還有很多挑戰，所以我們希望順利過渡。