2020年中頃のGAリリースに向けて、Jakarta EEプラットフォームプロジェクトチームは、Jakarta EE運営委員会(steering committee)に公式なJakarta EE 9のデリバリ計画を提出した。ツーリングベンダが新しいjakartaパッケージネームスペースをサポート可能になること、アプリケーションの開発チームによる新しいネームスペースへのマイグレーションテストが可能になること、ランタイムベンダがマイグレーションテストとJava EE 8との後方互換性をサポートするためのオプションと機能をテストおよび提供可能となることから、Jakarta EE 9は安定したツーリングリリースになるものと期待されている。Jakarta 10およびそれ以降の新機能を進める上での、イノベーションの基盤として位置付けられる可能性もある。
OracleがJava EEの新たな住処としてEclipse Foundationを選択した時、Microsoft AzureのJava関連のプリンシパルプログラムマネージャであるReza Rahman氏は、Javaコミュニティを対象にした2件の調査への参加を呼び掛けた。最初の調査は2017年8月に実施された、Java EEの名称変更の是非を問うもので、回答者の3分の2がJava EEの名称の維持を支持した。2017年11月に実施された第2の調査では、OracleがEclipse Foundationに対して、Javaの商標とjavaxパッケージネームスペースの継続を許可するべきがどうかを問うものだった。この時は、4分の3の、回答者がこの行動を支持した。Oracleに対するコミュニティ共同の公開書簡の中でRahman氏は、これらの結果を要約すると同時に、現在の状態を継続すべき理由をいくつか列挙した。具体的には、Java EEが強力なブランド力を保っていること、名称変更が市場の混乱を招く可能性があること、Java EEはオープンソースプラットフォームとして価値を持つべきであること、などだ。
Ecllipse FoundationとOracleの間で交渉が行われ、2019年5月、Javaの商標に対するJakarta EEの権利として、Javaの商標はOracleの独占的財産であり、Eclipse Foundationには使用権のないことが確認された。結論は次のとおりだ。
javaxパッケージネームスペースはJakarta EE仕様内部では使用可能だが、"現状維持(as is)"のみで使用する。Jakarta EE仕様内でのjavaxパッケージネームスペースへの変更は認められない。javaxパッケージネームスペースを引き続き使用するJakarta EE仕様は、対応するJava EE仕様のTCKに今後も準拠しなければならない。javaxパッケージネームスペースを使用するJakarta EEコンポーネント仕様は、将来的なJakarta EEプラットフォーム仕様から完全に削除される可能性がある。- 仕様の名称は"Java EE"命名規則から"Jakarta EE"命名規則に変更されなければならない。これにはEJB、JPA、JAX-RSなどの短縮名も含まれる。
TomitribeのCEOであるDavid Blevins氏は、javaxからjakartaへのパッケージネームスペース移行のソリューションとして、すべてを一気に移行する"ビッグバン"と、必要に応じて徐々に行う"インクリメンタル"という、それぞれメリットとデメリットのある2つの提案を行った。反応としては"ビッグバン"への賛同が多いように思われたが、Blevins氏はそこで止まらなかった。Jakarta EEプラットフォームのGitHubリポジトリ内に、"javaxからjakartaにネームスペースを変更することによるさまざまな影響に関する情報を収集する非公式なwiki風の場所"として、namespaceセクションが新たに設けられた。この理由について氏は、次のように説明する。
情報を収集して整理しなければ、1か月の議論はまったくの無駄になってしまいます。自由に議論をした2週間を要約できないことを理由に、コントリビューションはあっという間になくなってしまうことでしょう。
transitivecBlevins氏のバイトコード分析により、Jakarta EE APIの依存関係やjavaxからjakartaへのマッピング、Jakarta EE APIの推移的(transitive)変更など、複数のドキュメントが作成された。
Elicspe FoundationのエグゼクティブディレクタであるMile Milinkovich氏は先日、Jakarta EE9に向けた動きについて論じるとともに、このリリース計画を開発したJavaコミュニティの努力を認め、次のように書いている。
開発には多くの時間とエネルギが費やされています。このアプローチが極めて幅広いコンセンサスを獲得すべく、... 熱のこもったと言っていいのか ... 議論が繰り広げられているのを目の当たりにするのは、エキサイティングなことです。特にSteve Millidge、Kevin Sutter、Bill Shannon、David Blevins、Scott Starkといった方たちがプロセスの先導的立場で行っている、時に報われない不断の努力による貢献には大きなものがある、と私は思っています。
2019年を振り返って、Milinlkovich氏は、初めて開催されたJakartaOne仮想カンファレンスの成功、Jakarta EEが"Duke's Choice Award"の受賞者に加わったこと、昨年に引き続いて行われた年次の"Jakarta EE developers survey"の公開、といったハイライトも取り上げた。
Jakarta EE委員会の責任により、Jakarta EEプロジェクトプラットフォームチームは、ロードマップとリリース計画の策定、少なくともひとつの仕様準拠実装が存在することの保証、運営委員会と仕様委員会に対する定期的な更新提供、といった作業に責任を負うことになる。これはすべてのJakarta EEリリースの要件であると同時に、Jakarta EE Specification Process(JESP)に準拠している。リリースプランの策定では、メーリングリストや週次のJakarta EEプラットフォームテレカンファレンスを通じて、Javaコミュニティからの入力を広く受け付けている。
Payaraの創業者でCEOのSteve Millidge氏は、リリース計画を決定した背後にある根拠を論じて、次のように記している。
java-jakartaに必要なネームスペースの変更に伴って、後方互換性を損なう大きな変更が発生します。プロジェクトではこれを、古いAPIを多数取り去り、また一部はオプション(つまり、新しいアプリケーションサーバでは実装不要)にすると同時に、古いネームスペースで記述されたアプリケーションに対する後方互換性を不要にする機会にします。これはつまり、JDK 11の新しいネームスペース内のJakarta EE 9 APIのみをサポートすれば、Jakarta EE 9に完全に準拠したアプリケーションサーバを新たに提供可能である、ということです。私にとってこれは大きな勝利であり、新しいJakarta EE 9ランタイムによるイノベーションの機会を私たちに与えてくれると同時に、Jakarta EE 9プロダクトにおいて古いアプリケーションをサポートする選択肢も依然として残されているということなのです。
Oracleでプロジェクトマネジメントを担当するシニアディレクタのWill Lyons氏は、Jakarta EE 8リリースを改善の面を中心に捉えた自身の考えを要約して、次のように記している。
レトロスペクティブの目標は、Jakarta EE 8の提供プロセスに関するフィードバックを収集して、それを今後のリリースを改善するためのアクションアイテムに転じることと、できる限り多くのコミュニティからの参加を可能にすることにありました。
改善の領域には仕様やリリース管理、コミュニケーション、組織化といったものが含まれている。それに呼応する形で、Jakarta EE運営委員会では、これらすべての領域における改善を重視する予定である。
2019年9月に正式リリースされたJakarta EE 8は、javaxパッケージネームスペースを使用したJava EE 8として提供された。Jakarta EE 9の大きな目標は、Jakara EE 8に相当する仕様を、jakartaパッケージネームスペースによる仕様の実装で提供することにある。
リソース
- "Update on Jakarta EE Rights to Java Trademarks" — Mike Milinkovich (2019/5/3)
- "Jakarta EE 9 Release Plan" — Jakarta EE
- "Summary of Community Retrospective on Jakarta EE 8 Release" — Will Lyons (2020/1/13)
- "Moving Forward with Jakarta EE 9" — Mike Milinkovich (2020/1/16)
- "Jakarta EE 9 Release Plan Approved" — Steve Millidge (2020/1/27)