英文原文：Jakarta EE: No turning back
Jakarta EE 正在為企業版 Java 開闢新的道路。在這篇文章中，Cesar Saavedra 將解釋為什麼說 Jakarta EE 為企業版 Java 帶來了新鮮的空氣。
首先，作為一名具有 30 年經驗的 IT 老兵，我曾經是開發者、服務顧問、技術銷售人員和技術營銷人員。從出現開源軟件和 Java 開始，我就一路看著 IT 和軟件市場的發展。對於我們這些長期浸淫 IT 的人來說，無論出現什麼樣的新技術，它們似乎總是試圖解決自計算機誕生以來我們就一直在嘗試解決的問題（封裝、可重用性、可用性、分佈式系統、數據管理等等）。
我還記得 90 年代第一次參加 Java 研討會（由 Sun Microsystems 組織）。除了吸引人的“一次編寫，到處運行”口號，作為一名開發人員，我充滿對這種門語言的敬畏之情，因為我不再需要為分配和釋放內存而操心，並且可以保證可移植性。這兩項功能將為我節省大量的開發時間！然後是 Java 企業版（JPE -> J2EE -> Java EE），它提供了一組 API 用於開發企業級功能，很多企業發現這些功能對於開發生產應用程序來說非常有用，這些應用程序到現在仍然在全球範圍內運行。Java 仍然是當今最頂級的語言之一。
Jakarta EE 簡介
然而，我們現在生活在一個不同的時代，雲計算、容器、微服務、迷你服務、API 管理、無服務器計算、反應式系統已經成為在數字經濟中獲得競爭力並取得成功的必要條件，因為新經濟時代要求在開發、交付和維護應用程序方面具備超敏捷性。現在已經有大量適用於微服務和雲計算的運行時和框架。
例如，Node.js 在微服務開發中變得非常流行，而 Java EE 不再是唯一基於 JVM 的框架，Spring 和 Eclipse Vert.x 是另外兩個可以考慮的框架。使用單一的編程語言來開發應用程序的日子已經一去不復返。
事實上，在 Red Hat 最近的一次客戶調查中，87％ 的受訪者表示，他們正在使用或者考慮使用多種技術來開發微服務。同樣的，在 2018 年 Eclipse 基金會 Jakarta EE 開發者調查中，68％ 的受訪者表示，他們有超過 60％ 的應用程序在實現過程中使用了多種語言。
對於全球的企業和開發人員來說，Java EE 仍然具有其價值和生產力，但是作為一個標準，Java EE 已經落後於雲計算、容器和微服務。正因為如此，社區決定在 2016 年“不畏艱險”地創建了 MicroProfile——這是一個社區驅動的開源規範，現在與 Eclipse 基金共存——專注於為微服務而優化企業版 Java。很多反對者多年來一直宣稱“Java EE 已經死亡”，儘管這在某種程度上說的是事實，但最近作為 Eclipse 項目 Jakarta EE 出現的 Java EE 正帶來一些重大的變化。
Jakarta EE 作為雲原生 Java 的新家，從甲骨文手中接過 Java EE，計劃在 2018 年第三季度發佈符合 Java EE 8 規範的的 Glassfish 5.1，並基於新的認證流程在 2018 年第四季度發佈符合 Jakarta EE 8 規範的 Glassfish 5.1，以此來確保交接的完整性。
其他可在 2018 年交付的包括 Java EE 8 規範、RI、TCK、現有規範和新規範的流程、兼容性過程等。目前，Eclipse 基金會正在組織 Jakarta EE 子項目。下一步，Jakarta EE 將開始啟動在雲計算、容器、微服務、無服務器計算和反應式技術方面的快速演化進程。Jakarta EE 在 2018 年計劃：
- 得到充滿活力的開發者社區的支持
- 增強對微服務架構的支持
- 轉到雲原生 Java
- 更快的創新：變得更加敏捷
- 提供具備生產級質量的參考實現
此外，Jakarta EE 將通過以下方式讓生態系統變得更加現代化：
- 使用新的開放規範流程取代 JCP
- 新的治理結構
- 更開放的貢獻方式
Eclipse MicroProfile
加快 Jakarta EE 發展的一個關鍵因素是它與 Eclipse MicroProfile 的緊密結合。在撰寫本文時，Eclipse MicroProfile 1.4 和 2.0 已經包含了 Configuration、Fault Tolerance、Metrics、JWT propagation、Open API、Open Tracing、Health Check 和 Rest Client 的企業級規範，並可以與 Java EE 7 或 Java EE 8 結合使用。
由於 MicroProfile 和 Jakarta EE 之間的高度協同作用，後續的雲平臺可以通過採用這些 MicroProfile 規範快速走上軌道。兩個社區已經就提升這兩個開源項目的一致性展開了討論。現在說結果如何還為時尚早，不過有可能出現以下這些情況：
- Eclipse MicroProfile 移至 EE4J 下，由 Jakarta EE 工作組負責治理。
- Eclipse MicroProfile 移至 EE4J 下，並繼續使用自己的治理流程。
- 保持現狀，作為 Eclipse 基金會的一個單獨項目，每個項目都有自己的治理流程。
無論如何，Eclipse MicroProfile 可以繼續作為一個快節奏的孵化項目，新想法不斷出現，並交由開發人員去實驗和改進。這些 MicroProfile API 已經被用在市場中，並根據社區和用戶的反饋進行加固，所以 Jakarta EE 可以將它們作為候選。正因為如此，我認為，在兩年時間內（甚至更早），Jakarta EE 將包含針對微服務架構、容器、雲計算、API 管理、無服務器計算、反應式系統和服務網格的完整規範。
為什麼開發人員會愛上 Jakarta EE
支持雲原生 Java 並不是 Jakarta EE 唯一的目標。世界上有成千上萬家企業仍然信任使用 Java EE 來處理他們的生產負載。在 Red Hat 最近的客戶調查中，Red Hat Middleware 客戶使用或考慮將 Java EE 用於微服務的三大原因是：
- Java EE 是一種標準
- 不需要重新培訓員工
- 我們信任 Java EE，因為它已經很成熟，而且是企業級的
此外，在 2018 年 Eclipse 基金會 Jakarta EE 開發者調查中，受訪者表示，他們所在組織選擇 Java EE 的最重要原因是：
- 穩定性
- 規範
- 開發人員的可用性
- 多個供應商提供兼容性的實現
很顯然，市場仍然青睞社區驅動的開源規範，因為開源規範讓企業在選擇實現時更加自由，他們可以充分利用開發人員的專業知識或在就業市場中更容易找到具備這些種技能的人才。
此外，有很多組織其實不需要微服務。不是每個企業都要成為 Uber 或 Netflix。在大多數情況下，Java EE 工作負載將在未來幾年繼續運行在生產環境中。有一部分公司，由於業務性質的關係，不能在生產中進行“實時測試”，例如金絲雀發佈、藍綠部署、A/B 測試等。如果你的電影無法播放或者你的出租車沒有出現，那都沒有關係，但對於運送給移植病人的心臟或飛機導航系統的 bug，根本沒有重來一次的機會。
不過，採用敏捷方法 / 框架進行開發有明顯的好處，例如容器、雲計算、CI/CD、DevOps 等，因為所有這些都支持數字化。事實上，根據 2016 年貝恩公司和 Red Hat 數字化轉型的調查，數字化成熟度較高的公司獲得市場份額的可能性是普通公司的 8 倍。
Jakarta EE 的未來
因此，在 Jakarta EE 的發展過程中，它還必須想方設法保留受組織信任的 Java EE 功能。這在 Jakarta EE 中將會是什麼樣子？以下是社區目前正在討論的一些注意事項：
- 可以將現有的完整配置標記為“穩定”或“建議可選項”，這樣社區就可以專注於與雲計算、容器、微服務、互聯網 /Web 規模、高度分佈相關的新功能。
- 擺脫配置的概念，並採用可組合 API 模型，也就是一種應用程序組裝方法（類似於 WildFly Swarm，最近更名為 Thorntail），通過它創建的應用程序只需要 Jakarta API，而不需要其他東西。
- 需要在 Jakarta EE 中保留最小化的核心配置，可以基於這個核心配置構建其他配置。
- 需要定義多少個配置？可能需要核心（Servlet 或 CDI 或兩者）、Web、微服務、完整和自定義。
- 提供一個遺留的完整配置（為了向後兼容）和一個新的完整配置，新配置包括雲原生企業 Java 規範（無遺留配置），以及少數其他子配置。
- 集成或包含服務網格。
- 上述選項的組合。
很顯然，Jakarta EE 需要在未來幾年內保留 Java EE 的關鍵功能，以便為現有的 Java EE 客戶提供一條通向新 Jakarta EE 的途徑。同樣，現有的 Java EE 企業將能夠逐步利用 Jakarta EE 的新雲原生功能，同時仍然可以使用 Java EE 的關鍵功能。他們還應該有足夠的時間將標記為“建議可選項”的 Java EE 功能遷移到新的 Jakarta EE 功能。
Jakarta EE 和微服務
說到 Java 微服務，不得不提及 Spring Boot，它已經變得非常流行。Spring Boot 和 Spring 也是基於 Java，是 Jakarta EE 的競爭對手。Spring Boot 採用了 Dropwizard 和 Pivotal 的“fat jar”概念。Pivotal 是 Spring Boot 背後的公司，正在推動“雲原生”一詞，這個詞最初是由 Netflix 發明的，目前已經在市場上得到廣泛使用。
儘管在容器和微服務變得流行之前就已存在雲原生應用程序，但這些極大地影響和改變了雲原生應用程序開發。fat jar 的概念正在被分層容器鏡像所取代，容器鏡像被證明更加有效，並加快了雲原生應用程序的交付。
在運行時方面，想要採用微服務架構的組織大多朝著 Node.js 和 Spring Boot（以及 MicroProfile，根據 2018 年的 Eclipse 基金會 Jakarta EE 開發者調查結果，從項目建立第 1 年的採用率就達到了 15％）的方向發展。雖然一些應用程序服務器非常適合微服務架構，但 Java EE 不僅慢而且太耗資源的說法已經在市場上傳播開，一棒子打死了所有應用程序服務器。
但這些說法現在不再有任何立足之地了。Jakarta EE 將具備雲原生企業級 Java 功能，組織因此有了微服務和雲原生應用程序開發的另一種選擇。
有更多的框架和語言可選擇對於開發人員來說是件好事，他們現在已經習慣了使用正確的工具來完成正確的任務。Spring 的所有者 Pivotal 與 IBM、Red Hat、甲骨文、微軟、富士通、SAP、Lightbend 等公司一起參與了 Jakarta EE 工作組。那麼，這對 Spring 的未來意味著什麼呢？Jakarta EE 和 Spring 將如何發展？這裡有很多可能性：
- 通過協作，Pivotal 將 Jakarta EE 發展成為社區驅動的雲原生企業級 Java 規範，從而將功能彙集到單個規範中。
- Jakarta EE 未能佔領市場，Spring 成為雲原生企業 Java 的唯一可選項。
- Jakarta EE 取得市場份額並取代 Spring。
- Jakarta EE 與 Spring 共存。
結論
無論兩年後會發生什麼，我認為開發人員已經取得了勝利。因為所有這些供應商、用戶組、開源社區成員和公司齊聚 Jakarta EE，並聯手開發雲原生企業 Java 規範，這將為所有人都帶來好處。
Jakarta EE 是企業版 Java 的新曙光。
閱讀更多 JAVA技術程序員 的文章
