5月3日に、Jakarta EEでのjavaxパッケージ名前空間の使用についてアナウンス(*1)がありましたが、javaxを拡張できない(*2)ことは、Java EEからJakarta EEへの移行において大きな問題となります。
Jakarta EE.next (Jakarta EE 9以降)において、Jakarta EE 8との互換を最大限保証し、jakartaパッケージ名前空間へのスムーズな移行のために、Jakarta EEワーキンググループの仕様策定委員会では２つの案を提示(*3)し、
開発者からのフィードバックを求めています。この２つの案は出発点にすぎず、それ以外の案の提案も歓迎しています。
以下が２案の概要。
案１ Jakarta EE 9でビッグバン、Jakarta EE 10で新機能
すべてのAPIを、javaxからjakartaに一気に変更することにより、
移行に伴うコストと痛みを１回限りにおさえる。
Jakarta EE 9ではパッケージ名の変更だけで新機能の追加はしない。
Jakarta EE 10で新機能を追加するが、Jakarta EE 9のリリース前に、検討を開始する。
案２ Jakarta EE 9で段階的に変更
仕様の拡張が必要なものから、順次javaxからjakartaに変更していくことで、
移行に伴う最初のコストを最小限におさえる。
仕様の変更(JavaMailなどの塩漬けAPI)がないものは、javaxのまま。
Jakarta EE 9では、javaxとjakartaパッケージが混在する。
Jakarta EE 10でも混在するが、Jakarta EE 9と混在具合が違うことになる。
(*1)
原文 https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/
日本語 https://qiita.com/kazumura/items/7f87afb0d2fdc7f42e2b
(*2)
拡張できない例
- enumに値を追加する
- メソッドをオーバーライドや追加する
- interfaceにデフォルトメソッドを追加する
- Java言語仕様の変更に対応した変更
(*3)
https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html