2022年10月における次期メジャーリリース Jakarta EE 11 の方向性

はじめに
Unified Platform(統一されたプラットフォーム)
- What?
- Why?
- コメント
Add New Specifications(新しい仕様の導入)
- What?
- Why?
- コメント
Leverage Latest Java(最新のJavaを活用)
- What?
- Why?
- コメント
Enable Community Innovation(コミュニティ・イノベーションを実現する)
- What?
- Why?
- コメント
Clarify Compile Time Support(コンパイルタイムサポートの明確化)
- What?
- Why?
- コメント
Continuous Integration
- What?
- Why?
- コメント
JakartaOne Livestream Japan 2022 からのフィードバック
Continue refactoring platform TCKs(プラットフォームTCKのリファクタリングを継続)
- What?
- Why?
- コメント
CDI Centric
- What?
- Why?
- コメント
まとめ

Jakarta EE 11 の現在の状況については以下を参照してください。

blog1.mammb.com

はじめに

先日 Jakarta EE 10 がリリースされましたが、コミュニティでは次のメジャーリリースについての検討が行われています。

ここでは、2022年10月10日期限で行われた、Jakarta EE 11 のメジャーリリースの優先順位について、ワーキンググループのメンバーからフィードバックの内容を紹介します。

メジャーリリースの優先順位については narrative for future direction として行われていますので、方向性のみです。

https://docs.google.com/presentation/d/1rugEgECY-ghIIbYlsBtlDb0CTk4aeOFG/edit#slide=id.p1

Unified Platform(統一されたプラットフォーム)

What?

CDI上の仕様を統一ビーンモデルとして統一する
APIの凝集度を高める
「上位」仕様を「下位」レベルの仕様に基づいて構築し、横断的な関心事(cross-cutting concerns)を提供する。
- 例えば、Jakarta Authentication、Jakarta Authorisation、Jakarta Concurrency

Why?

開発者が理解すべき Bean モデルが 1 つとなり学習曲線が短縮される
ある仕様が他の仕様と合わせた場合に、期待通り動作しないエッジコンディションがなくなる
ランタイム作成者の実装が簡素化される

目的として「Jakarta EE API の更新と MicroProfile の要件に沿った Core Profile を提供する」を追加したい
根拠として「開発者/ユーザーと実装プロバイダーのためにAPIと実装を整合させる」を追加したい
個々のAPIや価値を高めるAPIに対する更新をコミュニティに奨励することを明示したい
Jakarta Configをベースにした統一コンフィギュレーションはもう一つのポイントになるかもしれない
- しかし、これにはまず、他のコンポーネント仕様からJakarta Configを使用できるようにするための別のマイルストーンが必要になるかもしれない
必ずしもフルプラットフォームでなく、コンポーネントAPIレベルで達成可能です
私の見解では、APIとそれに対応するTCKにおいて、依存関係のバージョンを一貫して使用することは必須要件です
- MicroProfile の要件に合わせるために Core Profile の内容を修正することに同意します
- 潜在的な候補： Jakarta Config、 Jakarta Bean Validation を追加すること
これは良い目的だと思います。EJBの時代を超えて、技術が本当に進化していることを示すことになると思います
これはまた、正しく行われた場合には、循環的な依存関係をより早く検出することを意味します
- 実装に依存するコンポーネント仕様は、循環的な依存関係を作るので、それを取り除く必要がある
- 現時点では、Jakarta Transaction、 Mail、 Faces がこの点に関してさらなる検討を必要としている

Add New Specifications(新しい仕様の導入)

What?

新しい仕様のプラットフォームへの導入（例：Jakarta Config、Jakarta RPC)
新しい仕様の機能を、必要に応じて既存の仕様に取り入れる

Why?

新しい仕様が開発中であり、リリーストレインに乗せるべきである
Jakarta EEプラットフォームが新しい機能を提供し、将来の開発にとっての重要性を市場に示す

HTTP/3のサポートは、Java SEで対処されていない場合に追加すべきかもしれない
Jakarta Data / Jakarta MVC の追加
すべてのプラットフォームタイプに統一されたデプロイメントがあれば、アプリのデプロイだけでなく、TCKのデプロイの方法についても統一されたものになるでしょう
これは特に Configuration、 gRPC、 JWT、 NoSQL、 Data/Repositories といった、よりクラウド・ネイティブな技術にとって大きな目標になります

Leverage Latest Java(最新のJavaを活用)

What?

Javaベースラインの更新によって提供される機能をすべての仕様で使用する
最新のJavaベースラインをサポートするために、仕様の改訂を行う
recode、 Virtual Thread(JDK 19+)の更新

Why?

開発者は最新のJavaの機能を新しいアプリケーションで使いたいと考えており、Jakarta EEに期待している
Jakarta EEが最新のJavaを追跡し、Enterpriseで活用することを市場にメッセージする

Jakarta Concurrency を含む特定の実装や仕様において、Java の仮想スレッドを採用するを追加したい
Platform 仕様で詳述されているスレッド制限を緩和するを追加したい
来るべきJava SE 21への対応が求められています
- コンポーネントの仕様から17以上の提供を必要とする正当な理由があれば、Java SEの最低レベルを21に設定することを考えるべきでしょう
これは良い目的です。少なくともレコードとの整合性は見るべきでしょう
ほとんどの人がJDKのベースラインとしてLTSを支持していました。これは、例えば Record のようなサポートとは相容れないものでしょう
- また、「開発者は最新のJava機能を使いたい」とありますが、開発者の大半は最新版ではなくLTS版を使っているのではないでしょうか

Enable Community Innovation(コミュニティ・イノベーションを実現する)

What?

コミッターとコントリビューターの数を増やす
仕様書、TCK、互換性のある実装の作成プロセスの簡素化
仕様、TCK、互換性のある実装のメンテナンス、拡張、利用の簡素化

Why?

機能や技術的な方向性についてのアイデアはあるが、それを実現するキャパシティがない
学習が困難なため、幅広いコミュニティが参加し、効果的に貢献することができない
自動化されていないフィードバックのループ、技術的・組織的な複雑さ、一貫性のなさなどから、リリースに時間がかかりすぎる

解決策としては、公式の Jakarta Template を作成し、Maven プラグインが共通の親から起動するようなテストに使用できるようにすることです
品質チェックのあらゆる面を自動化することで、迅速なフィードバックが可能になります
- 一元的かつ継続的な親の設定がここでも役に立つでしょう
現在のプロファイルのリリースやドキュメント、使用例との整合性により、プロファイルの一部ではない仕様に対するより良いサポートは、新しい仕様の成熟に役立つ可能性があります
運営委員会の特別な責任として、Jakarta (EE)のための明確なプロジェクト構造を定義し、そこからすべての側面のためのきれいな命名規則を導き出し、SemVerを強制することができます
- いくつかの部分はすでに存在していますが、更新や強化、そして多くの逸脱に対する管理が必要です
- 初心者のための障壁を下げ、自動化を単純化するために、これにいくつかの努力を費やす価値があると思います

Clarify Compile Time Support(コンパイルタイムサポートの明確化)

What?

Jakarta EE APIにおいて、JLink イメージや GraalVM Native Image のような技術のサポートを明確化し、拡張する

Why?

強い関心
一部のコンポーネントと Core Profile でのみ可能
サポートされる場所が必ずしも明確でない、またTCKのサポートがない
ランタイムリソースの節約

なし

Continuous Integration

What?

互換性のある実装でのTCKテスト実行を自動化し、製品認定だけに使用するのではなく、あらゆる変更に対する迅速なフィードバックに使用することができる
テスト実行の簡素化
テスト実行のスピードアップ
問題のある成果物のリリースを防止する

Why?

変更に対する迅速なフィードバックの提供
品質とリリースサイクルを向上させるとともに、必要なリソースを削減
リリースプロセスにおけるTCKの早期かつ頻繁な実行を奨励する
リリース管理への自動的なフィードバック(詳細なテスト結果やKPIなど)
互換性のあるインプリメンテーションを提供するためのベンダー関与の透明化

jQAの依存性解析や、TCKをコンポーネント仕様とプラットフォームプロファイルに分割する作業など、いくつかの努力はすでに終わっていますが、きれいなプロジェクト構造や一貫した命名規則など、多くのことが未解決です
より良い品質の製品になるため、+1。
これが確立され安定すれば、Adpotium AQAvit を介して、最新の Java SE の変更を自動的にテストするように拡張することができます
- 一部の実装のテストスイートだけを実行するのではなく、Jakarta EE TCKも実行して、OpenJDKの変更から、あるいは変更に対する初期のフィードバックを得ることができます

JakartaOne Livestream Japan 2022 からのフィードバック

JakartaPersistenceが使いにくいので、再設計してほしい
アプリケーションサーバ間の差異が少なくなるように、共通化を進めて欲しい
アノテーション構成の導入(@AliasFor)
Spring Securityなど、Jakarta EE でうまくカバーできていない部分が使えるようになると良い
レコードクラス、モジュールなどは Jakarta EE で使えるようになるのでしょうか？
Log4J2になったLoggingフレームワークの再標準化、Session Beanの廃止とCDIへの統一、JPA仕様の簡略化と高速化、KaflkaなどのストリームAPIの標準化、KVSアクセスAPIの標準化などです
ハンズオンやチュートリアルがあると嬉しいです
Webアプリケーションはフロントエンドとバックエンドを分けて開発するのが一般的ですが、バックエンドでAPIを認証するアプリケーションを Jakarta EEや MicroProfile を使って開発する際のベストプラクティスがあれば、チュートリアルをお願いしたいです
アクションベースの MVC が標準の Spring Framework に対して、JSF しかない JavaEE の採用には苦労しましたが、Jakarta MVC が知られた今、将来的に Spring Framework から Jakarta EEに戻す良い機会かもしれません
裾野を広げる意味でも、簡単なチュートリアルを用意してもらえると嬉しいです
ビューに関して、JakarataEEとして何をしようとしているのかが気になります
microprofile.ioとの統合、Web pofile の軽量化
後方互換性をなるべく保ってほしい
今後、定期的なリリースを期待します