Jakarta EE 對開發人員需求的回應效果如何？

交叉發佈在 Ed Burns 部落格上。

執行摘要

Jakarta 指導委員會特許了 Jakarta 平台項目，其目標是在 EE 11 的開發中納入開發人員的回饋。這篇部落格文章回顧了該平台專案的效能，並以 4 分制的方式授予 GPA 3.43 的成績目標。

介紹

我很榮幸也很榮幸能夠幫助交付 Jakarta EE 的下一個版本。幾十年來，我在 J2EE/Java EE/Jakarta EE 中擔任過許多角色：實施者、規範負責人、倡導者、作者、測試人員等等。然而，我目前的角色對我來說是一個新的發布協調員。

在此職位上，我（與 Arjan Tijms 一起）共同領導 Jakarta 平台項目，該項目負責交付完成的 Jakarta EE 規範（和組件規範）、相應的 TCK，並至少批准兼容的實現所有規格。重要的是，不需要有一個單一的整體實現同時滿足所有組件 TCK，但必須有一個透過平台 TCK 的單一整體實現。

本著二十多年前我有幸開始的透明精神，這篇博文探討了雅加達平台項目在EE 11 期間在實現指導委員會為平台項目設定的目標之一方面的表現：納入開發者反饋。

承諾不足和交付太多

制度記憶是人類群體從錯誤中學習並避免重蹈覆轍的方式。根據這個定義，我希望我們都能同意機構記憶很重要且值得保存。因為軟體是可執行的知識，所以長期運作的開源軟體專案是一種特殊的機構記憶。由長期運作的開源專案組成的長期運作的生態系統的專案幾乎是特殊的頂峰。考慮到所有這些特殊性，納入開發者回饋意味著什麼？

當犯錯的可能成本包含在單一專案中時，顯示對開發人員回饋的回應要容易得多。鑑於可能的高成本，Jakarta EE 11 平台專案故意保持低調，以實現納入開發人員回饋的目標。這是我們對「承諾不足、交付過多」這項久經考驗的策略的實施。

在 Jakarta EE 11 發布之前，我們對 Jakarta EE 11 的要求進行了公開社區討論，並將其記錄在本 Jakarta EE 11 討論文件中。讓我們回顧一下我們收到的社群意見（主要是由開發人員驅動的），看看我們在 EE11 中的表現如何。

承諾不足

• 雅加達資料

• 雅加達 NoSQL

• 採用 Java SE 11、17、21 新功能和重大變更

• 虛擬執行緒

• TCK 重構

• 以 CDI 為中心

  • CDI 取代託管 Bean
  • CDI 取代 EJB

• 解決冗餘 HTTP 堆疊：Servlet 和 REST

• MicroProfile 和 Jakarta 對齊

• CORS 支援

• 雅加達配置

• 讓從一個供應商遷移到另一個供應商變得更容易

混合出貨

我將把交付分為四類：超額交付、已交付、部分交付、未交付。

超額交付

• Jakarta Persistence - 程式設定而不是 persistence.xml 以及更多 Gavin King 部落格文章
• Jakarta Security - 動態選擇驗證機制 security-311

發表

• 雅加達資料

  • 是的，這個新規範已出現在平台中。

• 採用 Java SE 11、17、21 新功能和重大變更。

  • 是的，有許多規範利用了 11 - 21 的新語言功能。

• TCK 重構（我們將交付此內容。我們正在為其保留發布版本）。

  • Jakarta EE 平台 TCK 是一個重要的軟體元件，可實現數十年規模的 IT 投資穩定性價值主張。由於缺乏維護投資，TCK 的軟體一直在累積技術債。在 Jakarta EE 11 中，我們讓 TCK 與最先進的測試工具保持同步。隨著 Jakarta EE 平台的發展，這項投資將實現更好的兼容性測試，並降低添加更多測試的障礙。

• API 靈活性，即不再需要 Umbrella JAR。

  • 不再有類似「我必須等待 Jakarta EE xx」才能擁有此功能的問題嗎？
  • Jakarta EE Platform API 現在只是預設 API 的集合。
  • 個別規格可以由使用者依需求排除或升級，
  • 也可以新增規格。
  • 這使得 Jakarta EE 平台像 Spring Boot 一樣靈活，但應用程式中沒有實現包袱，兩全其美！

有點交付

• 虛擬執行緒

  • 並發規範嚴格指定了註解屬性，要求實作利用虛擬執行緒（如果虛擬執行緒在執行時可用）。如果您在 Java 21 或更高版本上執行，則在使用註解屬性時會取得虛擬執行緒。如果你在 17 號跑步，你就不會。

• 以 CDI 為中心

  • CDI 取代託管 Bean。

    • 我們做到了
      • 刪除@ManagedBean註解。
      • 將 CDI 的「整合」部分從 CDI 規範移至平台規範。
      • Jakarta Concurrency 在 @Asynchronous 註釋中添加了調度，以替換 EJB 並發上的 @Scheduled 註釋 - 271
      • 將並發資源注入 CDI bean，而不是在 EJB 並發中使用 @Resource-348。
      • 刪除了 Jakarta REST 中的託管 Bean 支援。
      • 持久化中持久化單元的限定符 - 允許以 CDI 慣用方式註入持久化上下文。

• Java 新功能

  • 在 Jakarta Persistence 中記錄為可嵌入項目和 ID。
  • 用表達語言記錄。
  • Validation（先前的 Bean Validation）validation-275 中的記錄。
  • 並發中的 Flow API concurreny-368。

• MicroProfile 和 Jakarta 對齊

  • 我們做到了
    • 建立 Jakarta Security MicroProfile 安全橋規格。

沒有交付

• 雅加達 NoSQL

  • 這在 EE 11 開發週期開始時沒有通過投票。在我看來，原因是非技術性的，因此可以在 EE 12 中解決。

• 解決冗餘 HTTP 堆疊：Servlet 和 REST

  • 這是一個非常大的。在我看來，需要一個主要供應商來支持這個想法，並投入大量資源來實現它，可能會向競爭對手捐贈工作，這樣他們也可以做同樣的事情。

• CORS 支援

  • 這個甚至沒有出現在我的雷達上。

• 雅加達配置

  • 這個似乎陷入了「MicroProfile 配置夠好」的困境，因此陷入了困境。我認為我們必須說服 MicroProfile 專案允許其從 MicroProfile 轉移到 Jakarta EE Core Profile 規格。

• 讓從一個供應商遷移到另一個供應商變得更容易

  • 這與每個供應商的商業利益是對立的，所以我認為這一點不會受到太多關注。

概括

讓我們定量一下。對於Underpromise清單中的每一項，我都會給我們一個字母等級。 A 表示超額交付或交付，B 表示部分交付，D 表示未交付。

Feedback to incorporate	Grade
Jakarta Data	A
Jakarta NoSQL	D
Adopt Java SE 11, 17, 21 new features and Breaking Changes	A
Virtual Threads	A
TCK Refactoring	A
CDI Centric	A
Resolve redundant HTTP stacks: Servlet and REST	D
MicroProfile and Jakarta Alignment	B
CORS support	D
Jakarta Config	D
Make it easier to migrate from one vendor to another	D

透過這份清單，我們的 GPA 只達到了 2.54。不太好。如果我們從清單中刪除我認為不切實際的開發人員回饋請求（CORS、冗餘HTTP 堆疊、Jakarta 配置、使從一個供應商遷移到另一個供應商變得更容易），我們會得到更好的分數：3.43。不錯，但我們還有成長的空間。

以上是Jakarta EE 對開發人員需求的回應效果如何？的詳細內容。更多資訊請關注PHP中文網其他相關文章！