1999 年，Sun 公司正式發佈了 J2EE 的第一個版本。到現在，Java EE（2006 年 J2EE 更名爲 Java EE）算起來已經有 19 年的歷史了。在過去的這些年裏，Java EE 曾經引領並深深影響了企業級 Web 應用開發以及相關標準，可以說也是世界互聯網技術發展歷史上的一個重要技術。但現在，一切都不同了。
寫在前面
2017 年夏天，Oracle（Sun 公司早已被 Oracle 收購）表達了想要開源 Java EE 的意圖，緊接着又宣佈希望將 Java EE 移交給 Eclipse 基金會管理，這被很多開發者認爲是 Java EE 發展的重要里程碑之一。因爲後面這些年，Java EE 的開發已經跟不上時代變化，並且迭代速度已經到了讓人難以忍受的地步。這也許是 Oracle 求變的方式之一。
緊接着在 2017 年的 10 月，Eclipse 基金會表示正準備將 Java EE 基於 Eclipse Public License 2.0 許可協議，並作爲 Eclipse Enterprise for Java（EE4J）項目進行開源，包括 Oracle、RedHat、IBM 等項目都會參與其中。
但是，接下來的進展看起來並不好，也在意料之中，在我（InfoQ 編輯）理解來看衝突還主要是 Oracle 商業利益以及開源社區之間。其實，Oracle 在 2017 年 9 月宣佈將 Java EE 所有權轉交給 Eclipse Foundation 時，曾明確表示希望 Java EE 重命名。
Java EE 守護者也擔心 Oracle 會限制使用 EE4J 中的“Java”和“javax”相關的包名（不瞭解的同學可以看看 Google 和 Oracle 的官司）。聊聊架構也報道了 Java EE 將會重命名爲 Jakarta EE 的消息，並且爲了避免法律風險，包換也有可能會對應更換，甚至包括類和接口（還沒有得到確認，還在討論中）。
前段時間，Java EE 守護者 Jean-François James 撰寫了系列文章，來探討未來 Java EE 的發展方向，InfoQ 爲了幫助大家瞭解這個項目目前的進展以及狀態，同步進行了翻譯。以下爲全文。
Oracle 開源 Java EE 的動機
據 Oracle 的 Java EE 佈道師 David Delabassee 透露，Oracle 之所以要開源 Java EE，主要是想讓它變得更敏捷，以適應快速發展的行業和技術需求。
事實上，儘管 JCP（Java Community Process）也在這方面做出了一些努力，但仍然無法趕上現代 IT 市場快速發展的步伐。從 2013 年 6 月發佈 Java EE 7 以來，出現了很多新興技術，比如 NoSQL、容器、微服務和無服務器架構，但它們都未能被包含在 Java EE 當中。
在我看來，這一決定顯得有點唐突，因爲它與 Oracle 在 JavaOne 2016 上發佈的路線圖完全背道而馳。
當然，這一決定也表明了 Java EE 不再是 Oracle 的首要關注點。Oracle 似乎把更多的注意力放在新的開源項目 Fn 上，Fn 是一個無服務器框架，類似亞馬遜的 Lambda 和 IBM 的 OpenWhisk（現在是 Apache 項目）。
2017 年 9 月 21 日，Java EE 正式發佈。我們先來看看 Java EE 8 的主要變更。具體如下：
與 Java SE 8 同步：DateTime API、CompetableFuture 和可重複註解。
CDI 2.0：異步事件、事件保序以及與其他規範更好的集成。
Servlet 4.0：支持 HTTP/2（服務器端推送）。
JAX-RS 2.1：服務器端發送事件、反應式擴展。
JSON Processing 1.1 和 JSON Binding 1.0。
安全：簡單化、祕鑰管理、現代化、OAuth2 和 OpenID 支持。
總的來說，Java EE 8 更像是大躍進，而不是小步快跑。不過，雲原生相關應用並沒有包含在 Java EE 8 中，如分佈式跟蹤、集中式配置、健康監測、迴路斷路器、負載均衡。
Java EE 的現狀是怎樣的？
對於大多數企業來說，Java EE 仍然是一個非常有價值的平臺：
完善而靈活的編程模型。
單一的依賴管理：通常一個 Maven 的 pom.xml 不會包含超過 20 行配置代碼，即使項目很複雜。
CDI 易用且強大。
可以與大多數 IDE 集成。
有很多輕量級的應用服務器，比如 TomEE、Payara、Red Hat Wildfly 和 IBM Liberty，它們不僅啓動速度快，而且佔用資源小。
可以使用 Java EE 來開發容器化的微服務，雖然不完美，但也不失爲一種選擇。
在我看來，Java EE 的不足在於：
不夠先進：儘管它還有一定的價值，但大部分開發者並不會將它作爲開發雲原生應用的首選。
因爲組件模型的差異，缺乏整體的一致性：Servlet、CDI、EJB……確切點說，CDI 和 EJB 之間的界限有點模糊，或許 CDI 在未來會成爲“第一類公民”。
測試相對複雜。
規範及其實現的演進速度較慢。
與 Java SE 不同步：要想在 Java EE 中看到 Java 9 的模塊化系統尚需時日。
Java EE 生態系統的演化
Oracle 的決定給整個 Java EE 生態系統帶來重大影響。
Oracle
作爲 Java 技術（包括 Java EE）和品牌的所有者，Oracle 仍然會繼續負責維護 Java EE 8。
但這種所有權在品牌和未來的技術發展方面存在一些限制，比如：
不能再使用 Java EE 作爲品牌名稱。
在新名稱中使用 Java 要經過多方討論和允許。
不能再使用 javax 包名。
JCP
JCP 旨在“爲 Java 技術制定標準技術規範”。但 JCP 幾乎爲 Oracle 所掌控：項目管理辦公室、選舉、投票、規範管理等等。從組織角度來看，JCP 是開放的，它歡迎任何人加入，IBM 和 Red Hat 就是非常重要的成員。同時，JCP 涵蓋了 Java EE 中的很多規範，如 Servlet、EJB、CDI、JAX-RS……
其中每個規範都是以 JSR（Java Specification Request）的形式進行管理的（比如 Java EE 8 對應 JSR 266，Servlet 4.0 對應 JSR 369，CDI 2.0 對應 JSR 365，CDI 2.1 對應 JSR 370），並由專家組負責管理每個規範的生命週期。
專家組要交付三個方面的內容，包括規範文檔、規範的參考實現以及測試套件。
從外部來看，這個流程太過笨重：從規範的啓動到最終發佈需要很長時間，而應用服務器實現規範也需要一些時間。
從內部來看，作爲 JCP 的成員，我不得不承認，JCP 的監管質量和人們的投入程度給我留下了深刻印象。或許它的步子邁得不夠快，但話說回來，在制定一個標準時，創新又佔有多大比重呢？
EE4J 最爲成功的一個方面在於它的敏捷性，它能夠很快建立起強壯且靈活的監管模型。
Java EE Guardians
Java EE Guardians 由“一羣致力於通過社區和擁護者來推動 Java EE 平臺發展的草根組成”。Reza Rahman 在 2015 年成立了 Java EE Guardians，旨在催促 Oracle 重啓 Java EE 8，因爲當時的 Java EE 8 處於停滯狀態。
該組織目前專注於保護 Java EE 品牌和 javax 包，讓它們得以延續，他們在 2018 年 1 月份發表的一封公開信中說明了他們的目的。具體如下：
https://javaee-guardians.io/2018/01/02/joint-community-open-letter-on-java-ee-naming-and-packaging/
Microprofile.io
Microprofile 把自己定義成“一個基準平臺，以微服務架構爲基準來優化企業版 Java，並交付可在多個 Microprofile 運行時上運行的應用程序”。它從 2016 年夏天啓動，現在已經成爲了 Eclipse 的項目，最初貢獻者包括 TomiTribe、IBM 和 Payara，Oracle 也在 2017 年 11 月加入其中。
Microprofile 的第一個版本在 JavaOne 2016 上發佈，涵蓋了 JAX-RS 2.0、CDI 1.2 和 JSON-P 1.0。
從那以後，社區同時開始了多個項目，包括：
microprofile-config
microprofile-fault-tolerance
microprofile-health
microprofile-metrics
microprofile-open-api
microprofile-jwt-auth
Microprofile.io 的最初目標是專注於 JCP 標準的快速創新，而現在也可以被認爲是 EE4J 在社區、組織和監管方面的“POC（概念性驗證）”。
Microprofile.io 的未來將去向何處？與 EE4J 合併抑或是繼續保持獨立？現在還沒有定論。
EE4J
EE4J 的章程上寫道：“Eclipse Enterprise for Java（EE4J）是一個開源倡議，旨在建立和實現標準 API，爲 Java 運行時提供技術工具，促進服務器端和雲原生應用的開發、部署和管理。EE4J 以 Java 平臺和 Java EE 標準爲基礎，並在 Java EE 8 的基準上建立新的標準”。
需要注意的是，EE4J 只是項目的名稱，而不是一個品牌。2017 年 11 月份，他們爲尋找合適的品牌名稱進行過一次問卷。但因爲受到上述的一些限制，至今未達成共識。不過，社區當中有 79% 的人似乎希望能夠保留 Java EE 這個品牌。
2017 年 11 月，項目管理委員會成立，成員來自原先的 Java EE 生態系統。委員會的首要任務是完成過渡、建立新的社區，以及基於 Java EE 8 發佈第一個版本。
目前有兩個項目正式成爲 EE4J 的一部分：
Yasson：JSON-B 的參考實現。
EclipseLink：JPA 的參考實現。
開源（Java EE）對於廠商的影響
對於 Java EE 廠商（Red Hat、IBM、TomiTribe 和 Payara）來說：
他們在 JCP 中將擁有更多的話語權和影響力。
他們可以自由地訪問測試套件，而之前它是屬於 Oracle 的。
他們可以迭代推出“應用服務器”，不需要再承受 Java EE 新版本發佈的“隧道效應”所帶來的痛苦。
應用服務器的未來
新的 Java EE 會成爲“保護傘”抑或是由一系列獨立的規範組成？
由此引申出的問題是：應用服務器會繼續扮演“單體平臺”的角色，還是會變成可組合的模塊平臺？
我傾向於選擇第二種可能，Red Hat 的 Wildfly Swarm 就是最好的例子。
開源 Java EE 對開發者社區的影響
對於開發者社區來說，這是一個很好的機會，他們需要一個敏捷的平臺來促進創新。
對於開發者個人而言，參與 EE4J 是一個非常好的提升個人影響力的途徑。
王者風範
對於用戶來說，目前的處境很艱難。Java EE 的優勢在於一系列由 JCP 推動的官方標準，而依賴這些標準對於長期項目來說是至關重要的。
Java EE 的上一個階段已經走到了尾聲，不管高興與否，我們都要繼續與它共同前行。新的 Java EE 標準將爲我們帶來什麼？沒有了 JCP 的支持，EE4J 將如何發展？
這一切要取決於行動的快慢和實際結果的產出。我粗淺地認爲，這將受到以下幾個因素的影響：
時間：之前已經提到，儘管 Java EE 8 仍有它的價值，但它並不是最先進的，所以它需要儘快縮小差距，以便在競爭中勝出。如果 EE4J 要花幾個月“才能”交付一個版本，那麼要實現這個目標就會很困難。
與 Microprofile.io 協作：Microprofile.io 已經在雲原生應用方面發力，所以完全可以利用它，把它集成到 EE4J 中。
社區：EE4J 社區將發展壯大到怎樣的程度？
還是時間：廠商和開源項目是否有能力及時交付符合 EE4J 規範的平臺？Java EE 最大的一個問題就是從規範最終版的發佈到應用服務器的實現需要很長的時間。
不過，就像昨天文章中評論的那樣，不管名字是否改變，面對 Spring 框架的強力衝擊，Java EE 路在何方，現在還不好說。從目前社區熱點來看，我只知道，Spring Boot、Spring Cloud 這套框架很受歡迎。
對於 Spring 生態和 Java EE 的關係，Jean-François James 也做了評論（另外一篇文章）。
Java EE 和 Spring 的複雜關係
在之前評估 Java EE 生態系統對 EE4J 發展的影響時，我漏掉了一個非常重要的因素：Pivotal 和它的 Spring 框架。
Java EE 和 Spring 之間的關係已經進入了“最好的敵人”模式。
Spring 誕生於 2004 年，由 Rod Johnson 發起，作爲對 J2EE（Java 2 Platform，Enterprise Edition）和 EJB 2 複雜性的反擊。從那個時候開始，Spring 和 Java EE 之間就沒有停止過競爭，並彼此影響對方：
Spring（以及 Hibernate）的出現刺激了 Java EE 社區，促使他們推出了 EJB 3 和 JAP 1.0。
Spring Batch 直接影響到了 Batch 規範（JSR 352）。
Spring Dependency Injection 啓發了 CDI（Context and Dependency Injection）。
Spring 恰到好處地使用了 J2EE 和 Java EE 中的某些標準，如 Servlet、JMS 和 JPA。
Spring 5 宣稱兼容 Java EE 8。
從誕生之日起，Spring 就因爲超強的實用性受到了開發者的青睞，而且它的演進速度很快，可以快速地集成新技術：NoSQL、AMQP、微服務、雲原生應用……
從 2006 年開始，Java EE 也將提升易用性和對開發者的友好放在首位，但在演進速度方面還是很慢，主要有兩個原因：
JCP 制定規範需要很長時間：即使是一個輕量級的規範，也需要多方參與，需要更長的時間才能達成一致。
實現和認證：在規範發佈之後，需要幾個月時間才能找到符合認證的應用服務器。
而最近，這方面的差距在加大：
Spring Boot 將“以約定代替配置（Convention Over Configuration）”的原則發揮到了極致，進一步提升易用性。
Spring Cloud 利用 Netflix 的開源組件解決了與雲原生應用開發相關的問題，如服務註冊、服務發現、彈性、負載均衡、監控……
Spring 5 將反應式編程提升爲一等公民。
Java EE 在這方面的速度要慢的多。在 2013 年發佈 Java EE 7 之後，經歷了一段消停期。2016 年，在社區的壓力下，Oracle 才發佈了一個新的路線圖。
Java EE 8 發佈於 2017 年 9 月，雖然人們對其期望甚高，但並非革命性的。人們還是把更多的目光投向了 Java EE 9，期望下一個版本會有更多的創新。
與此同時，Eclipse 基金會於 2016 年中啓動 Microprofile.io 項目，旨在以微服務架構爲基準來優化企業版 Java，以此來推動 Java EE 生態系統的發展。Microprofile 1.0 涵蓋了 JAX-RS 2.0、CDI 1.2 和 JSON-P 1.0，1.2 版本於 2017 年 9 月發佈，加入了更多特性，如配置、容錯、JWT、度量指標和健康檢測，2.0 版本有望與 Java EE 8 看齊。
過渡到 EE4J
EE4J 旨在提供一種更加靈活的協作方式，但要成功，有一些前提是不可或缺的：
Java EE 8 遺留資產的轉移（規範文檔、參考實現和測試套件）。據 David Delabassee 所述，這項工作已經在進行當中。
建立新的監管模型和操作系統，在最近發佈的工作組章程中已經提到了這一點。
建立活躍的社區。
品牌和包的重新命名：Oracle 不允許 EE4J 在新規範中重用“Java EE”這個商標和 javax 這個包名，所以需要重新起一個名字。
在滿足了這些條件之後，EE4J 就可以繼續演進，適應雲原生應用和 Java SE 平臺（特別是 Java 的模塊化系統）的變更。
大一統的時機？
除了監管和技術之外，EE4J 必須爲自己找到合適的位置，因爲沒有了 JCP 的支持，它作爲標準的地位就不復存在。在這樣的情況下，EE4J 已無力與 Spring 展開競爭。或者說，整個 Java 生態系統經不起這樣的“內戰”。Java 在應用服務器方面的霸主地位已經一去不復返，它必須與其他平臺展開競爭，比如 Node.js、Go 和 Python。如果能夠將整個社區甚至整個行業的力量帶動起來，那就更好了。
爲什麼不呢？如果 EE4J 能夠推出一些獨立的兼容規範，Spring 團隊就可以參與進來，讓 Spring 成爲 EE4J 的主要參與者。