Beyond Jakarta EE 11 - A Memorandum

Jakarta EE 11 のその先へ

2024年01月 Jakarta EE Working Group により新しい仕様のアイデアが議論されている。この議論の草案として以下のようなトピックが挙げられており、以下に紹介しておく。

注目トピック

量子コンピューティング

Java開発者がアプリケーションの一部として、量子コンピューティングを活用する方法を改善できるか？

Java開発者のための量子コンピューティング

AI/ML

AIやMLをJavaアプリケーションに統合するためのAPIや利用パターンはあるか？

機会を探るサブグループ設立の可能性
データ管理や検証技術・テクノロジーとの接続を容易にするAPI
プライベートLLMに接続するためのAPI
Javaアプリケーションを構築する際に生成AIツールが使用するデータに影響を与えるベストプラクティスとパターンを成文化

Robotics

ロボティクスの分野で、APIを通じて現在利用可能なもの以外に、標準化やJava言語サポートによって恩恵を受ける分野はあるか？クラウドへの影響も考慮に入れる。

Edge Computing

コンピューティングをエッジに近づける - IoTからクラウドまでの分散リソース。リアルタイム・アプリケーションの検討(LTI、低レイテンシー)、ヘルスケアにおけるアプリケーションの追加(例：緊急ボタン) MQTTプロトコルをJMSまたはMQTT仕様に - 直接通信を可能にするために独自のソリューション/APIを用意すべきか、用意されたソリューションを使うべきかを判断

Supersede EJB

EJBはプラットフォーム全体にとって、マーケティング上の大きな障害となっている。早急に決定的に取って代わらなければ、他に何をしようとも認識を変えるのは難しいと考えられる。

私たちがすべきものには、以下がある

@Transactionalアノテーションを使用して、EJBの外部でEntityManagerをスレッドセーフな方法でプレーンなCDI Beans にインジェクトして使用する方法を定義
RolesAllowed と @RunAs に CDI に適した現代的な同等品を提供
Schedule と @Lock に CDI に適した同等品を追加
MaxConcurrency アノテーションの追加
EJB @Stateless と同様の機能を提供しようとする @Service CDI ステレオタイプを導入する。
MDB に対する CDI フレンドリーな同等品を提供する

Modernize Messaging

Jakarta EEエコシステムにおけるメッセージングといえば、Jakarta Messaging、IBM MQ、ActiveMQなどを連想する人がまだ多い。もし我々がメッセージング分野でより強固な足跡を残すべきだと感じるのであれば、Messaging Lite を検討すべきだ。

これは、マーケティング／認知の観点から非常に重要だろう。本質的には、クラウドネイティブのユースケースに向けた Messaging の近代化されたサブセットになるだろう。これを実現するための実際の作業はそれほど多くないかもしれない。これに沿って、Messaging 用の JavaSE/スタンドアロンブートストラップAPIを提供するのもいいだろう。また、Teams や Slack などの一般的なメッセージング・プラットフォームとの統合も検討しよう。

Modularity

どのようにすれば、さまざまな組み合わせでスペックを使用しやすくなるか？

ユーザーが個々のスペックを選択し、依存関係があれば自動的に含まれるようにする。プロファイルを増やしても、この問題には対処できない。

Spec support

特定の仕様が委員会から支持を得られず、前進できない理由を探る
どの仕様が使用され、どの仕様が使用されていないのか、そしてその理由を明らかにする
開発者が、どの仕様が特定のタスクに適しているかを知るための簡単な問い合わせフォームを提供する
スペックとその依存関係を可視化する方法を提供する
開発シナリオを検討し、どの仕様がそれらをサポートしているかを判断する。どのようにすれば、より顧客中心の方法で、あるいは生成的AIをよりよくサポートするステートメントベースで、情報を表面化できるか
ドキュメントとチュートリアルは、明確で簡潔で、ChatGPT+その他が簡単に解析できる一貫したアプローチを使用する