Eclipse Foundationのエグゼクティブディレクターを務めるマイク・ミリンコビッチ氏によると、Jakarta EE 9の目的は「javax」という文字列を含むパッケージ（拡張機能）名を「jakarta」に変更することだ。Eclipse Foundationは、今回の名前変更を「ビッグバン」と呼んでいるという。

　Jakarta EE 9では非推奨メソッド（処理）の削除や、バグの修正といった内容の変更は一切ない。変わるのは名前だけだ。Jakarta EEのパッケージのうち、名称にjavaxを含むものにひも付くクラス（データおよびデータの操作に使うメソッドの定義）やインタフェース（クラスが実装するメソッドの名前やデータ型などの定義）、列挙型（複数の定数をまとめたデータ型）の名前が変わる。例えば「javax.servlet.GenericServlet」というクラス名は「jakarta.servlet.GenericServlet」になる。

　この変更が必要になったのは、主に法的な理由による。OracleはJava EEをEclipse Foundationに寄贈したが、「Java」という単語の商標は引き続きOracleが所有するためだ。

　Java EE準拠コンポーネントを利用するアプリケーションの開発者は、Jakarta EE 9ベースのアプリケーションサーバ（APサーバ）に該当アプリケーションを移行する際、作り直しが必要になる。開発ツールやデプロイ（配備）ツールも変更しなければならない。

　例えば統合開発環境「Eclipse IDE」で、APサーバで稼働するJavaアプリケーション「Java Servlet」（Javaサーブレット）を作成するとする。このときJavaサーブレットを動かすためのAPサーバとして、Jakarta EE 9準拠の「Apache Tomcat 10」を利用したとしても、Eclipse IDEのデフォルトのクラス名はJava EEベースのクラス名だ。Eclipse IDEが従う規則にはJakarta EE 9のクラス名は存在しないため、エラーが発生して「プログラムが破損している」と警告を受けてしまう。

Jakarta EE 9に対する開発者の対応

　ソフトウェアベンダーOpenValueでCTO（最高技術責任者）を務めるベルト・ヤン・シュライバー氏の考えは「Jakarta EE 9は開発者向けの新機能はなく、主に開発用ツール向けのバージョンだ」というものだ。開発者がJakarta EE 9に切り替えるとしたら、その主な目的はアプリケーションをJakarta EE 9準拠にして次のJakarta EE 10に備えることだとシュライバー氏は指摘。「Jakarta EE 9をスキップし、次のJakarta EE 10を待つことも選択肢だ」と語る。

　シュライバー氏は「まずJakarta EE 9に移行して次にJakarta EE 10に移行するという段階的な方法を選びたい」と言う一方で「状況次第でその判断は変わる」とも話す。利用するAPサーバでまだJakarta EE 9が使えなければ、移行しても意味がないからだ。

　「Jakarta EE 9の初期リリースをパッケージ名変更のみにとどめるという判断が、開発者コミュニティーが取るべき対処をシンプルにした」とシュライバー氏は評価する。「もし名前変更の他に新機能も追加されていたら、もっと複雑な対処が必要になっていただろう」（同氏）