何ヶ月間にも及ぶ交渉の末、Eclipse FoundationとOracleは、javaxパッケージ名前空間のEclipse Foundationコミュニティによる修正や、現在Java EE仕様に使用されているJavaの商標使用について、合意に達することができなかった。この結果、今後Jakarta EEの後援によって実施される、フレームワークに対する更新と改良は、すべて違うパッケージ名になるため、アプリケーションとライブラリコードの移行が必要になる。
Eclipse FoundationのエグゼクティブディレクタであるMike Milinkovich氏は、Eclipse Foundationのブログ記事"Update on Jakarta EE Rights to Java Trademarks"の中で、javax.*パッケージの使用に関する交渉の終了を報告した。同記事では、過去のパッケージのライセンス権に関する合意が示されると同時に、それらの仕様と、Test Compatibility Kitの発展形としてのJakarta EEの将来的な実装については、明確に線引きされている。"つまり、次のようなことです"、とMilinkovich氏は言う。
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といった頭字語がこれに含まれる。
パッケージ名を変更することで所有権の曖昧さはなくなり、Java EE 8以下はSunとOracleの管理下で開発されたもの、Java 8より以降はEclipse Foundationの主導によるもの、というように区別される。これらの変更は、javaxで始まるEE内の全APIに影響を与えることになる。EEはJava Servlet APIやJava Mail APIなどの重要なコンポーネントをホストしているため、この変更の影響は、Spring WebアプリケーションなどEE以外の多くのWebアプリケーションに波及する恐れがある。
Red HatのJBossテクニカルリーダであるMark Little氏が、 このリファクタリングに必要な取り組みの重大さについて、個人的に技術分析を行っている。
TwitterのスレッドではMilinkovich氏が、交渉が非常に複雑であること、Oracleがこれまでに多大な寄付をしてきたことを指摘している。
Oracleは、GlassFish、Jersey、Grizzlyなど、Java EEのリファレンス実装に数百万行のコードを提供しています。Java EE TCKも寄贈されました。それまでは機密性の高い、プロプライエタリなものでしたので、これは大きな一歩でした。数百万ドルというJava EEライセンス収入を伴うことを考えれば、これは非常に大きな資産だったのです。Oracleは、Java EE仕様全体における自社の著作権をライセンス提供していますが、この中にはSunとBEAで過去に行われた開発成果がすべて含まれているため、仕様全体の内容の非常に大きな割合を占めています。
パッケージ名が変更されると、開発者は、自分たちのアプリケーションとライブラリを、新たな名前空間を使用するように移植する必要がある。これによって、既存のアプリケーションは積極的にマイグレーションしなければならない、さもなくば、新たなJakarta EEとの前方互換性のリスクが発生する可能性がある、という互換性の問題が発生する。 IntelliJ IDEAやApache NetBeans 、Eclipseといった統合開発環境が、このリファクタリングの自動化には有効だ。ByteBuddyの作者であるRafael Winterhalter氏も、Twitterで、強力な実装エージェントを使ってパッケージ情報を動的に変更する方法について述べている。JSR-382の仕様リーダであるMark Struberg氏は、利用可能なその他の選択肢についても詳細に説明した上で、"いずれの方法にも何らかの欠点があって、どれがベストソリューションであるかは、まだ分かっていません"、と述べている。
この移行は、Java SEとJava EEの互換性に関する長い歴史の転換点となる。 "20年近く動き続けたソフトウェアが、理由もなく動作しなくなるなんて、とんでもない話だ。"と、PivotalのSpring Developer AdvocateであるJosh Long氏は嘆いている。"Java Community Process(JCP)ベンダ標準に準拠せよ、JCPは信頼できる、と言ってたじゃないか。"
コミュニティメンバから選出された専門家グループであるJCPは、これまでJava SE（JSR-386）とJava EE（JSR-000366）を推進してきたが、コンピュータプログラムに関連する機関であって、Javaに関連する法的商標に関しては影響力を持っていない。商標はJCP自体にも適用されるが、JCPは名称としてJavaを使用することを許可されている。
今回の事が起こるまで、Java Community Process for EEの適用性は、何年にもわたって業界の高い評価を受けてきた。2016年、Oracleの役員であるAnil Gaur、Thomas Kurian両氏は、Java EEの戦略をJCPと共同で発表した。Oracleはその後、2017年になってJava EEをEclipse Foundationに寄贈し、さらに1年後には、"今後のJava EE 8の機能強化に関しては、JCPプロセスの使用を推奨もサポートもしない"、と述べている。このプロセスはHeather Vancura氏の指揮の下で、Java SEでは現在も使用されている。
TomitribeのCEOであるDavid Blevins氏は、Jakarta EEのjakarta名前空間への移行に関するディスカッションへの参加を、開発者やアーキテクトに呼びかけている。このディスカッションは、2019年6月9日の終了が予定されている。この議論に興味があるならば、JCPの後継であるJakarta EE Specification Processに意見を求めたり、あるいは、新しいメーリングリストであるJakarta EE Platform Devに参加することも可能だ。