Jakarta EE 9.1
Jakarta EE 9のリリースから5か月後、Jakarta EE Working Groupは、Jakarta EE 9.1および関連するTCKのプラットフォームおよびWeb Profile仕様のリリースを発表した。2018年のデビュー以降、2019年のJakarta EE 8と2020年のJakarta EE 9の2つのメジャーバージョンがリリースされた。これは、開発者が次のことができる最初のインクリメンタルポイントリリースだ。JDK 11およびJDK 8でJakarta EE 9.1アプリケーションを開発およびデプロイする。Java SE 8以降に追加された新しいテクノロジーと新しいJava SE 11機能を活用する。既存のJakarta EE 9アプリケーションを変更せずにJava SE 11に移行する。Jakarta EE 9への移行に使用できるのと同じ簡単なプロセスを使用して、既存のJava EEおよびJakarta EE 8アプリケーションをJakarta EE 9.1に移行する。
現時点では、IBMとTomitribeを含むJakarta EE 9.1の5つの互換性のある実装があり、Open LibertyとTomEEはそれぞれTCKに合格したことが最近発表された。特に記載のない限り、すべてプラットフォームおよびWeb Profileの認定を受けている。
- IBM Open Liberty 21.0.0.3-beta: Java 8 (TCK) と Java 11 (TCK)
- Eclipse Glassfish 6.0 (TCK) と 6.1-RC1 (TCK)
- Apache TomEE 9.0.0.M7 Web Profile (TCK)
- Red Hat Wildfly 23.0.2.Final: Java 8 (TCK) と Java 11 (TCK)
- ManageCat ManageFish プラットフォーム (TCK)
TomitribeとApache Software Foundationが、TomEEをJakarta EE 9.1互換の実装として認定に至るのは長い道のりだった。TomitribeのCEOであるDavid Blevins氏は、このジャーニーとJakarta EE 10への道をふりかえり、InfoQに語っている:
Jakarta EE 9.1リリースは、Apache TomEEとApacheコミュニティにとって歴史的なものでした。TomEE、Tomcat、CXF、ActiveMQ、MyFacesなどを含むすべてのApacheプロジェクトは、Apacheの10年間のJava EEライセンスの有効期限が切れた2013年に、Java EE TCKへのアクセスを失いました。このアクセスは、2019年9月のJakarta EEの最初のリリースによって復元され、過去20か月で、TomEEコミュニティの3つの主要なEEバージョン (7、8 と 9) のギャップを埋め、Jakarta EE 9.1 Web Profileの認証のリリースを達成することができました。
2010年にJCPを去った後、ApacheはゲストメンバーとしてJakarta EE Working Groupに参加しました。これら2つのイベントの重要性は誇張することはできません。Jakarta EE 10のコアプロファイルを楽しみにしており、今後のJakarta EEリリースで10年近くの価値のあるアイデアを削ぎ落としています。それは大きな瞬間です。
Jakarta EE 10への道
2022年の第1四半期にGAリリースが計画されているJakarta EE 10の開発はすでに進行中であり、仕様の多くは現在更新されている。また、Jakarta Transactionsの @Transactional アノテーション、Jakarta Server FacesでのマネージドBeanの非推奨、Jakarta SecurityでのCDIの使用などJakarta EEプラットフォームですでにサポートされているJakarta Contexts and Dependency Injection (CDI) を補助するアライメントの改善にもフォーカスしている。
CDIの恩恵を受けるJakarta EE仕様には、次のものが含まれる: Jakarta Batchの注入可能なアーティファクト。Jakarta RESTful Web ServicesでのCDIインジェクションを優先し、@Context アノテーションを非推奨にする、Jakarta ConcurrencyにおけるCDIコンテキストの伝播の改善。
Jakarta EE 8およびJakarta EE 9をサポートするバージョンで確立されたJakarta Enterprise Beans仕様があるにもかかわらず、現時点でこの仕様がさらに開発される可能性はほとんどない。ただし、独立したJavaコンサルタントであるArjan Tijms氏は、この仕様を継続的にサポートすることの重要性の議論を次のように記述している:
Jakarta EE 10は、ほぼすべてのEnterprise Bean機能のCDIベースのバージョンを導入する予定です。これらの機能は、すでに代替手段がある
@TransactionalなどのEnterprise Beans機能とともに、新しいコードがJakarta Enterprise Beansテクノロジを使用する必要がないことを意味します。ただし、考慮すべき主要なユースケースがまだあります:
@Statelessアノテーションなど、まだ多くのEnterprise Beansを使用している既存のコードです。Eclipse GlassFishなどの古いテクノロジーは、由緒あるEnterprise Beansの実装を長期間維持する可能性が高く、仕様をすぐに廃止または削除する予定はありません。
Jakarta EE Working Groupは、Jakarta EE仕様が特定バージョンのJava SEとどのように整合するかを予測した目標も定義している。Jakarta EE 10で必要とされるJava SEバージョンを決定するための毎週のプラットフォーム呼び出しに関する議論により、3つに絞り込まれたオプションが得られた。Javaコミュニティには、お気に入りのオプションに投票する機会が設けられた:
- 選択肢 1: source=Java SE 11, bin=Java SE 11, TCK=Java SE 11+
- すべてのAPI JARのソース/言語レベルおよびバイナリレベルをJava SE 11にする。互換性のある実装は、11以降のJava SEバージョンを使用してTCKの通過で解放される。
- 選択肢 2: source=Java SE 11, bin=Java SE 17, TCK=Java SE 17+
- すべてのAPI JARのソース/言語レベルをJava SE 11にバイナリレベルをJava SE 17にする。互換性のある実装は、17以降のJava SEバージョンを使用してTCKの通過で解放される。
- 選択肢 3: source=Java SE 17, bin=Java SE 17, TCK=Java SE 17+
- すべてのAPI JARのソース/言語レベルおよびバイナリレベルをJava SE 17にする。互換性のある実装は、17以降のJava SEバージョンを使用してTCKの通過で解放される。
最終投票では、選択肢 1がJakarta EE 10の優先オプションであることが明らかになった。
開発者がJakarta EE 10に期待する詳細については、このブログ投稿に記述されている。
積極的なコミュニティ参加と主張を通じてJakarta EEを前進させることに取り組んでいるJava開発者の独立した草の根グループであるJakarta EE Ambassadorsは、Jakarta EE 10への貢献に関心のある開発者がこの貢献ガイドを利用できるようにした。