Beyond Jakarta EE 11

Jakarta EE 11 のその先へ

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


注目トピック

量子コンピューティング

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+その他が簡単に解析できる一貫したアプローチを使用する

Industry specific API Patterns

  • 異業種に共通する仕様の使用方法を特定し、どのようにパッケージ化し、同業他社に普及させるかを検討する。
  • Kubernetes特有の仕様?


その他のアイデア

Better defaults for Persistence

Jakarta EE アプリケーションでは、persistence.xml をオプション/空のマーカーにする。 多くのアプリケーションでは、これは全く問題ない出発点となる。 データ・ソースとPersistenceリソースがあれば有効にするだけの簡単なものである。

Less XML in Batch

XMLの代替としてJavaバッチジョブ定義APIを追加する。

Pluggable caching in Persistence

Persistence のセカンドレベル・キャッシュ・プロバイダとして JCache をサポートする。

Modern packaging

bootable/fat/executable な jar を Core Profile に必須にする。 最近のほとんどの実装では既に可能で、マーケティング的に有効である。

Incubator

Jakarta EE と Java の使用法に沿った新しいアイデアのためのインキュベーター・プロセスを模索する。

Translation

言語グループ間でより良いデータが利用できるよう、多言語への翻訳を行う。

Partnerships

アプリケーションのコーディング(ビルド、デプロイ、モニタリング)以外のライフサイクルの問題に焦点を当てている他のオープンソースコミュニティとの提携を検討する。

Spring Analysis

Springが持っているものを見直すべき - 明らかなギャップとQAを見直す。 マーケティングの観点から Jakarta と Spring の長所を比較し、Jakarta EE を向上させる。

Excluded from EE11

Jakarta MVC、Jakarta Config、Jakarta no-SQL、Jakarta RPC など。

Normativity of API Jars and module-info and package-info.java

現在のところ、どれも規範的なものではない。

これは祝福でもあり、呪いでもある。このスタンスを見直すべきか?