Ed Burns ブログにクロスポストしました。

エグゼクティブサマリー

Jakarta Steering Committee は、EE 11 の開発に開発者のフィードバックを組み込むことを目的として、Jakarta Platform プロジェクトを設立しました。このブログ投稿では、プラットフォーム プロジェクトのパフォーマンスをレビューし、これを達成する 4 段階評価で GPA 3.43 を獲得しました。ゴール。

導入

私は、Jakarta EE の次のイテレーションの提供を支援する立場にいることを恐縮し、光栄に思っています。私は数十年にわたり、J2EE/Java EE/Jakarta EE で、実装者、仕様リーダー、提唱者、作成者、テスターなど、多くの役割を果たしてきました。しかし、私の現在の役割は、リリース共同コーディネーターという新しい役割です。

この役割において、私は Jakarta Platform プロジェクトを (Arjan Tijms とともに) 共同主導しています。このプロジェクトは、完成した Jakarta EE 仕様 (およびコンポーネント仕様)、対応する TCK の提供、および少なくとも互換性のある実装の承認を担当します。すべての仕様。重要なのは、すべてのコンポーネント TCK を同時に満たす単一のモノリシック実装が存在する必要はありませんが、プラットフォーム TCK を通過する単一のモノリシック実装が存在する必要があることです。

私が幸運にも 20 年以上前に始めることができた透明性の精神に基づいて、このブログ投稿では、EE 11 中に Jakarta Platform プロジェクトが運営委員会によってプラットフォーム プロジェクトに設定された目標の 1 つをどのように達成したかを検証します。開発者のフィードバックを取り入れます。

過少約束と過剰納品

制度的記憶は、人間のグループが間違いから学び、同じことを繰り返さないようにする方法です。この定義によれば、制度上の記憶は重要であり、保存する価値があるということに私たち全員が同意できると思います。ソフトウェアは実行可能な知識であるため、非常に長期間にわたって実行されているオープンソース ソフトウェア プロジェクトは、特別な種類の組織の記憶となります。長期にわたって実行されているオープンソース プロジェクトの長期にわたるエコシステムであるプロジェクトは、まさに特別なものの頂点です。こうした特殊性を念頭に置いた上で、開発者のフィードバックを取り入れるとはどういう意味ですか?

間違いを犯した場合に発生する可能性のあるコストが 1 つのプロジェクト内に収まっている場合、開発者のフィードバックに応答することがはるかに簡単になります。コストが高くなる可能性を考慮して、Jakarta EE 11 プラットフォーム プロジェクトでは、開発者のフィードバックを取り入れるという目標を意図的に控えめにしました。これは、「過少約束と超過納品」という実証済みの戦略の実装です。

Jakarta EE 11 に向けて、Jakarta EE 11 の要件に関するオープン コミュニティ ディスカッションを実施し、それをこの Jakarta EE 11 ディスカッション ドキュメントにまとめました。主に開発者主導で受け取ったコミュニティからの意見を確認し、EE11 での成果を見てみましょう。

過小約束

• ジャカルタ データ

• ジャカルタ NoSQL

• Java SE 11、17、21 の新機能と重大な変更を採用

• 仮想スレッド

• TCK リファクタリング

• CDI セントリック

  • マネージド Bean に代わる CDI
  • EJB を置き換える CDI

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

• マイクロプロファイルとジャカルタの調整

• CORS サポート

• ジャカルタ構成

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

混合配送

配信を 4 つのバケット (超過配信、配信済み、ある程度配信済み、配信なし) にグループ化します。

過剰納品

• Jakarta Persistence -persistence.xml の代わりにプログラムによる構成など、Gavin King のブログ投稿
• Jakarta Security - 認証メカニズムを動的に選択します security-311

納品済み

• ジャカルタのデータ

  • はい、この新しい仕様はプラットフォームに存在します。

• Java SE 11、17、21 の新機能と重大な変更を採用します。

  • はい、11 から 21 までの新しい言語機能を利用する仕様が多数あります。

• TCK リファクタリング (これを提供します。リリースは保留中です)。

  • Jakarta EE Platform 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 サポートを削除しました。
      • 永続化の永続化ユニットの修飾子 - CDI 慣用的な方法で永続化コンテキストを挿入できるようにします。

• Java の新機能

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

• マイクロプロファイルとジャカルタの調整

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

配達されませんでした

• ジャカルタ NoSQL

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

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

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

• CORS サポート

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

• ジャカルタ設定

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

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

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

まとめ

定量的に見てみましょう。 Underpromise リストの各項目について、レターグレードを付けます。 A は過剰に配信または配信され、B はある程度配信され、D は配信されませんでした。

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