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 的單一整體實現。

本著二十多年前我有幸開始的透明精神，這篇博文探討了Jakarta 平台項目在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 プラットフォーム API は、単なるデフォルト API のコレクションになりました。
  • ユーザーは希望に応じて、個々の仕様を除外またはアップグレードできます。
  • 新しい仕様を追加することもできます。
  • これにより、Jakarta EE プラットフォームは Spring Boot と同じくらい柔軟になりますが、アプリケーションに実装の負担がなく、両方の長所を実現できます。

ある程度配信されました

• 仮想スレッド

  • 同時実行仕様には、ランタイムで仮想スレッドが利用可能な場合、実装で仮想スレッドを利用することを要求するアノテーション属性が厳密に指定されています。 Java 21 以降で実行している場合、アノテーション属性を使用すると仮想スレッドが取得されます。 17 日に実行している場合は、そうではありません。

• CDI セントリック

  • マネージド Bean に代わる CDI。

    • やった
      • @ManagedBean アノテーションを削除します。
      • CDI の「統合」部分を CDI 仕様からプラットフォーム仕様に移動します。
      • Jakarta Concurrency は @Asynchronous アノテーションにスケジューリングを追加し、EJB 同時実行性の @Scheduled アノテーションを置き換えます-271
      • EJB 同時実行で @Resource を使用する代わりに同時実行リソースを CDI Bean に挿入する - 348.
      • Jakarta REST でマネージド Bean のサポートを削除しました。
      • Persistence の永続ユニットの修飾子 - CDI 慣用的な方法で永続コンテキストを挿入できます。

• Java の新機能

  • Jakarta Persistence の埋め込み可能ファイルおよび ID として記録します。
  • 式言語でレコードします。
  • Validation (旧 Bean Validation) validation-275 のレコード。
  • 同時実行 concurreny-368 のフロー API。

• マイクロプロファイルとジャカルタの連携

  • やった
    • Jakarta Security MicroProfile Security ブリッジ仕様を作成します。

配達されませんでした

• ジャカルタ NoSQL

  • これは、EE 11 開発サイクルの開始時に投票を通過しませんでした。私の意見では、その理由は技術的なものではないため、EE 12 では解決できると考えられます。

• 冗長な HTTP スタックの解決: サーブレットと REST

  • これは非常に大きなものです。私の意見では、大手ベンダーがこのアイデアを支持し、それを実現するには多大なリソースを投入する必要があり、おそらく競合他社にも同じことができるように作業を提供する必要があるでしょう。

• CORS サポート

  • これは私のレーダーにも現れませんでした。

• ジャカルタ構成

  • これは、「MicroProfile Config があれば十分」という考えにとらわれているようで、板挟みになっています。これを MicroProfile から Jakarta EE Core Profile 仕様に移行できるように MicroProfile プロジェクトを説得する必要があると思います。

• あるベンダーから別のベンダーへの移行を容易にします

  • これは各ベンダーのビジネス上の利益とは相反するものであるため、あまり注目されないと思います。

まとめ

定量的に見てみましょう。 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

このリストでは、2.54 GPA しか獲得できませんでした。それほど素晴らしいものではありません。このリストから、含めることが現実的でないと判断した開発者フィードバック リクエスト (CORS、冗長 HTTP スタック、Jakarta Config、あるベンダーから別のベンダーへの移行を容易にする) を取り出すと、より良いグレードの 3.43 が得られます。悪くはないが、まだ成長の余地がある。

以上がJakarta EE は開発者のニーズにどの程度応えましたか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。