Java EEからJakarta EEへ

Java EEとJakarta EEの違い

1.名前と運営母体の違い

Java EEとJakarta EEは、実質的に同じ技術の系譜にありますが、運営母体と商標（ブランド名）が異なります。もっとも簡潔に言うと、名称変更の理由はJava EEが新しい組織（Eclipse財団）に移管され、名前が変わったものがJakarta EEです。Oracleが「Java」という商標（ブランド名）の利用を許可しなかったため、「Jakarta」という新名称になりました。

1. パッケージ名の変更

これが開発者にとって最も影響が大きい技術的な違いです。

• Java EE 8 まで: パッケージ名は javax.* でした。
  • 例: import javax.servlet.http.HttpServlet;
• Jakarta EE 9 以降: パッケージ名が jakarta.* に変更されました。
  • 例: import jakarta.servlet.http.HttpServlet;

※ 注意点: 移行期間である「Jakarta EE 8」までは javax.* が使われていましたが、Jakarta EE 9 から完全に切り替わりました。これにより、Java EE時代の古いライブラリがそのままでは動かないという互換性の問題が発生します。

2. バージョンの対応関係

移行の流れを整理すると以下のようになります。

バージョン	パッケージ名	内容・特徴
Java EE 8	javax.*	Oracle時代の最終版。
Jakarta EE 8	javax.*	Java EE 8と機能は完全に同じ。運営がEclipseに移っただけ。
Jakarta EE 9	jakarta.*	機能追加はほぼ無し。「パッケージ名の変更」だけを行ったバージョン。
Jakarta EE 10	jakarta.*	ここからが本当の進化。 新機能追加、古い機能の削除、モダン化（Core Profileの導入など）。
Jakarta EE 11	jakarta.*	最新版（Java 21対応など）。さらなる効率化。

3. 開発サイクルと方向性

Jakarta EE時代: 「Cloud Native Java」を掲げ、更新サイクルを早めています。Kubernetesやマイクロサービスとの親和性を高める方向で進化しています（MicroProfileというプロジェクトとも連携しています）。

Java EE時代: 数年に一度の大型アップデート。重厚長大で、クラウドやマイクロサービスの流行に乗り遅れがちでした。

まとめ

• Java EE: 過去の名前。javax.* パッケージを使う。更新は止まっている。
• Jakarta EE: 現在と未来の名前。バージョン9以降は jakarta.* パッケージを使う。活発に進化している。

これから新規開発する場合や、将来を見据えた改修を行う場合は、Jakarta EE（特に10以降） を選択するのが標準です。

Java EEからJakarta EEへの移行に関して：

Java EEからJakarta EEへの移行は、単なるバージョンアップとは異なり、破壊的変更（Breaking Changes）を伴う大規模な作業になることが一般的です。特にJakarta EE 9以降への移行はハードルが高くなります。

1. 最大の障壁：パッケージ名の変更（javax.* → jakarta.*）

これが移行における最大の問題点であり、すべての元凶です。OracleからEclipse Foundationへの移管に伴う商標の問題により、Jakarta EE 9以降、APIのパッケージ名が変更されました。

• 問題点:
  • コード内の import javax.servlet... などをすべて import jakarta.servlet... に書き換える必要があります。
  • Javaソースコードだけでなく、XML設定ファイル（web.xml, persistence.xml など）のスキーマ定義やプロパティ値も変更が必要です。
• 難易度:
  • 単純な文字列置換で済む場合もありますが、リフレクションを使用している箇所や、文字列としてクラス名を指定している箇所（設定ファイル等）は見落としやすく、実行時エラーの原因になります。

2. 依存ライブラリの「地獄」（Dependency Hell）

自社のアプリケーションコードを修正しても、サードパーティ製のライブラリがJakarta EE（jakarta.*）に対応していなければ動きません。

• 問題点:
  • Spring Framework、Hibernate、Jackson、Log4jなど、利用しているすべてのライブラリをJakarta EE対応バージョン（例：Spring Boot 3系、Hibernate 6系など）にアップデートする必要があります。
  • 推移的依存（Transitive Dependencies）： 利用しているライブラリAが、内部で古いライブラリB（javax.*依存）を使っている場合、そこで衝突やエラー（NoClassDefFoundErrorなど）が発生します。
• 難易度:
  • 一部の古いライブラリはJakarta EE対応版がリリースされていないことがあり、代替ライブラリを探すか、フォークして自分で修正する、あるいは「Eclipse Transformer」のようなツールでバイトコードを変換する等の高度な対処が必要になります。

3. アプリケーションサーバー/ランタイムの変更

アプリケーションを動かす基盤（ミドルウェア）も入れ替える必要があります。

• 対応関係の例:
  • Tomcat: Tomcat 9まではJava EE (javax)、Tomcat 10以降はJakarta EE (jakarta)。
  • WildFly / JBoss EAP: 新しいバージョンへの移行が必要。
  • Payara / GlassFish: 最新版への移行が必要。
• 問題点:
  • WebLogicやWebSphereなどの商用サーバーを使用している場合、ベンダーのサポート状況やJakarta EE対応バージョンのリリース状況に依存します。古いサーバーを使い続けることはできません。

4. JDKバージョンの強制アップデート

Jakarta EEの新しいバージョンは、古いJDK（Java 8など）をサポートしていないケースが多いです。

• 問題点:
  • Jakarta EE 10以降は、ベースとして Java 11 または Java 17 以上を要求することが一般的です。
  • これにより、「フレームワークの移行」と同時に「Java言語自体のバージョンアップ（モジュールシステム対応、API削除対応など）」も行う必要が出てきます。
• 難易度:
  • Java 8からJava 17へのジャンプアップは、それ自体が大きなプロジェクトになり得る規模です。

5. 廃止された仕様・削除された機能

Java EE時代には標準だった技術の一部が、Jakarta EEでは削除（Pruned）または分離されています。

古いレガシーシステムでこれらを多用している場合、最新技術（RESTful Web Services、JPAなど）への書き換え（リアーキテクチャ）が必要になる場合があります。

主な削除・分離機能:

XML Binding (JAXB), JAX-WS: Java SE 11でJDKから削除され、Jakarta EEでも仕様が整理されています。これらを依存関係として明示的に追加する必要があります。

EJBの一部: 古いEJB Entity Beans (CMP/BMP) などはサポートされなくなっているか、多くの実装で非推奨です。

CORBA: 完全にレガシー扱いとなり、利用が難しくなっています。

難易度:古いレガシーシステムでこれらを多用している場合、最新技術（RESTful Web Services、JPAなど）への書き換え（リアーキテクチャ）が必要になる場合があります。

難易度のまとめ表

項目	移行難易度	主な課題
ソースコード	中	javax から jakarta への置換、XML設定の更新。
ライブラリ	高	依存ライブラリ全更新、非対応ライブラリの排除・代替選定。
JDK	高	Java 8 → 17/21への移行が必須になるケースが多い。
サーバー	中	Tomcat 10など、ランタイム環境の総入れ替え。
レガシー機能	高	XML-RPC, CORBA, 古いEJB等のリアーキテクチャ。

移行を助けるツール

幸いなことに、この作業を支援するツールが存在します。

• Eclipse Transformer: コンパイル済みのJARファイル（javax.*依存）を、バイトコードレベルで変換して jakarta.* 対応にするツール。ライブラリが対応していない場合の最後の砦です。
• IntelliJ IDEA / Eclipse: IDEの移行支援機能（リファクタリング機能）が充実しています。
• OpenRewrite: ソースコードや設定ファイルを自動的に書き換えるための強力なツールレシピが存在します。

参考：主要コンポーネントの「境界線」

主に以下の「Jakarta EE 対応の境界線」を基準にチェックをしてください。この表の左側から右側へ移動する場合、難易度が高いこの「破壊的変更」への対応が必要になります。

コンポーネント	従来の環境（javax.*）	移行後の世界（jakarta.*）
Java (JDK)	Java 8 / 11	Java 17 / 21 (必須の場合が多い)
Tomcat	Tomcat 9 以下	Tomcat 10.1 以降
Spring Boot	Spring Boot 2.7 以下	Spring Boot 3.0 以降
Spring Framework	Spring 5.x 以下	Spring 6.x 以降
Hibernate	Hibernate 5.6 以下	Hibernate 6.0 以降
Struts 2	Struts 2.5 系	Struts 6.0 系 (※バージョン番号が飛びます)
Jakarta EE	Jakarta EE 8 (Java EE 8)	Jakarta EE 9 / 10
Servlet API	Servlet 4.0	Servlet 5.0 / 6.0

特に注意すべきパターン: もし「Struts 1」や「JDK 1.7以下」など、上記表の「従来の環境」よりもさらに古いものが含まれている場合、Jakarta EEへの対応の前に、まずそこからの脱却（モダナイゼーション）が必要になるため、難易度は「特大」になります。

関連するトピックス:

• Espressシリーズ Ver7.0 update 13 リリースノート
• Espressシリーズ – DB2へのJDBC接続について【Javaチャート・グラフ作成ツールEspressChart】
• チャート・グラフをWeb上に展開するプログラム【Javaチャート・グラフ作成ツールEspressChart】
• レポート・帳票をweb上に展開するプログラム【Java対応レポート帳票ツール：EspressReport】
• WebAPサーバ利用時の注意点【Javaチャート・グラフ作成ツールEspressChart】
• サーバ・ライセンスと開発キットを同じマシンにインストールする場合【Javaグラフ作成ツールEspressChart】
• EspressReport ES (ERES) 7.0、Linuxコンテナ技術でRedHat Connect認定
• Tomcatとのセットアップについて【Java対応レポート・帳票ツールEspressReport】
• チャートをWEB上で表示するサンプルの紹介[EspressChart]
• 旧バージョンのインストールが失敗する際の対処法【Javaチャート・グラフ作成ツールEspressChart】