Jakarta EEでのjakartaパッケージ名前空間への移行

5月3日に、Jakarta EEでのjavaxパッケージ名前空間の使用についてアナウンス(*1)がありましたが、javaxを拡張できない(*2)ことは、Java EEからJakarta EEへの移行において大きな問題となります。

Jakarta EE.next (Jakarta EE 9以降)において、Jakarta EE 8との互換を最大限保証し、jakartaパッケージ名前空間へのスムーズな移行のために、Jakarta EEワーキンググループの仕様策定委員会では2つの案を提示(*3)し、

開発者からのフィードバックを求めています。この2つの案は出発点にすぎず、それ以外の案の提案も歓迎しています。

以下が2案の概要。


案1 Jakarta EE 9でビッグバン、Jakarta EE 10で新機能

すべてのAPIを、javaxからjakartaに一気に変更することにより、

移行に伴うコストと痛みを1回限りにおさえる。

Jakarta EE 9ではパッケージ名の変更だけで新機能の追加はしない。

Jakarta EE 10で新機能を追加するが、Jakarta EE 9のリリース前に、検討を開始する。


案2 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