Javaの業務系プロジェクトに関わると必ず出会う「Jakarta EE」。なんとなくJavaの仲間だとはわかっても、Java SEとの違いや呼び名の変遷が整理できていない方も多いのではないでしょうか。
この記事では、初心者の方にもわかるように、Jakarta EEの正体と歴史を順を追って解説します。この記事を読むと以下のことがわかります。
- Jakarta EE（ジャカルタ イーイー）の正体と、Java SE（ジャバ エスイー）との違い
- なぜ「Java EE」から「Jakarta EE」に名前が変わったのか、その歴史的経緯
- javax.* から jakarta.* へのパッケージ名変更がなぜ起きたのか
- 現場で迷いがちな「SpringとJakarta EEの関係」についての基礎知識
Jakarta EEとは？ざっくりひとことで言うと
Jakarta EE（Jakarta Platform, Enterprise Edition）は、企業向けの大規模Javaアプリケーションを開発するための「標準仕様」のセットです。
「標準仕様」と言われてもピンと来ないかもしれません。身近な例えでいうと、電化製品のコンセントの形状が国ごとに統一されているのに似ています。コンセントの形が決まっているおかげで、どのメーカーの家電を買っても同じ壁のコンセントに挿して使えますよね。Jakarta EEも同じで、「Webアプリを作るならこういうAPI（機能を呼び出す窓口）を用意しましょう」というルールを決めているのです。
このルールに従って作られた製品をアプリケーションサーバー（Javaで書かれたWebアプリを動かすための土台となるソフトウェア）と呼びます。代表例は以下のとおりです。
- WildFly（Red Hat社）
- GlassFish（Eclipse Foundation）
- Payara（Payara社）
- Open Liberty（IBM社）
どのアプリケーションサーバーを使っても、Jakarta EEの仕様に沿って作ったアプリはほぼそのまま動きます。これが「標準」の強みです。
Java SEとJakarta EEの関係
Java SEとJakarta EEは「置き換える関係」ではなく「積み上げる関係」にあります。
Java SEが「Java言語そのものと、基本的な機能」だとすれば、Jakarta EEは「企業向けWebシステムを作るための追加装備」です。Jakarta EEを使うにはJava SEが必須で、Jakarta EE単体では動きません。
| 項目 | Java SE | Jakarta EE |
|---|---|---|
| 正式名称 | Java Platform, Standard Edition | Jakarta Platform, Enterprise Edition |
| 用途 | 汎用アプリ開発の基盤 | 大規模Web・業務システム開発 |
| 主な提供内容 | 言語仕様、JVM、コアAPI（Collections、I/O など） | Webアプリ向けAPI群（Servlet、JPA、CDI など） |
| 実行環境 | JRE / JDK | アプリケーションサーバー |
| 単独で動くか | 動く | Java SEが必要 |
用語補足：JVM（Java Virtual Machine）とは、Javaのプログラムを実行する仮想的なコンピュータのことです。JRE（Java Runtime Environment）はJVMを含む実行環境、JDK（Java Development Kit）は開発に必要なコンパイラなどを含む開発キットを指します。
Jakarta EEが提供する代表的な機能
Java SEだけでWebシステムを作ろうとすると、HTTP通信の処理やデータベース接続などを自前で実装する必要があります。Jakarta EEはそういった「よくある処理」を標準APIとして提供してくれます。
- Jakarta Servlet / JSP：HTTPリクエストを受け取ってWebページを返す仕組み
- Jakarta Persistence（JPA）：データベースのレコードとJavaのオブジェクトを結びつける仕組み（ORM）
- Jakarta RESTful Web Services（JAX-RS）：REST API（WebのAPI形式の一種）を作るための仕組み
- Jakarta Contexts and Dependency Injection（CDI）：依存性注入（必要な部品を外から渡してもらう設計手法）の仕組み
- Jakarta Enterprise Beans（EJB）：トランザクション処理や分散処理を扱う仕組み
- Jakarta Messaging（JMS）：非同期メッセージ（即時応答を待たずに処理を依頼する仕組み）のやりとり
名前の歴史：J2EE → Java EE → Jakarta EE
Jakarta EEは、実は過去に2回名前が変わっています。古い書籍やレガシーシステムで「J2EE」「Java EE」という言葉を目にすることがあるのは、このためです。
- 1999年〜2006年：J2EE時代 正式名称「Java 2 Platform, Enterprise Edition」。Sun Microsystems社が策定し、エンタープライズJavaの基盤として広く普及しました。
- 2006年〜2017年：Java EE時代 Java EE 5で名称が簡略化され「Java Platform, Enterprise Edition」に。2009年にSunはOracleに買収され、OracleがJava EEの管理を引き継ぎました。
- 2017年9月：Oracle、Eclipse Foundationへの移管を発表 Oracleは、Java EEをオープンソースコミュニティ主導の開発に委ねるため、非営利団体Eclipse Foundationへの移管を発表しました。
- 2018年：Jakarta EEへ改名 Oracleが「Java」の商標権を保持し続けたため、移管先は新しい名前を使う必要がありました。約7,000人のコミュニティ投票の結果、64%以上の賛成で「Jakarta」が選ばれました。この名前は、かつてApache Software Foundationが使っていた「Jakarta Project」から受け継がれたものです。
- 2019年9月：Jakarta EE 8 リリース パッケージ名はまだjavax.*のまま、中身はJava EE 8と完全互換でリリースされました。「箱だけ変わった」状態です。
- 2020年12月：Jakarta EE 9 リリース（big bang） javax.* から jakarta.* への一斉パッケージ名変更が実施されました。この大変更は「big bang」と呼ばれ、Javaの歴史における大きな転換点となりました。
なぜパッケージ名が javax.* から jakarta.* に変わったのか
この変更の理由は、技術的なものではなく商標上の制約です。Oracleは「Java」という商標権を手放しませんでした。そしてjavaxというパッケージ名には「Java」の名前が含まれているため、Eclipse Foundation側はjavax.*を自由に拡張・変更することが許されなかったのです。
例えるなら、人気ブランドの子会社だったお店が独立することになった際、親会社から「うちのブランド名は今後使わないでね」と言われたようなものです。看板も、商品タグも、店内の案内表示も、すべて新しい名前に塗り替える必要が出てきたわけです。
コード上の変更は以下のようになります。
// Java EE 8まで（古い書き方）
import javax.servlet.http.HttpServlet;
import javax.persistence.Entity;
// Jakarta EE 9以降（新しい書き方）
import jakarta.servlet.http.HttpServlet;
import jakarta.persistence.Entity;この「塗り替え作業」は一見すると単純ですが、既存のJavaアプリケーションのソースコードすべてに影響するため、移行には大変な手間がかかります。Eclipse Foundationは自動変換ツール「Eclipse Transformer」を提供して、この移行を支援しています。
実例で理解する：Jakarta EEを使うWebアプリ
たとえば、社内の勤怠管理システムをJavaで開発するケースを考えてみましょう。Java SEだけで作ろうとすると、開発者は以下のような作業を全部自前で書く必要があります。
- HTTPリクエストを受け取るTCPサーバーを書く
- リクエストの中身（URLやパラメータ）を解析する
- データベース接続やSQL発行を手書きする
- トランザクション管理（処理の途中で失敗したら全部取り消す仕組み）を実装する
- ユーザー認証の仕組みを自作する
これは大変な重労働で、しかもバグの温床になります。そこでJakarta EEを導入すると、以下のように置き換えられます。
| 担当処理 | Jakarta EEの機能 |
|---|---|
| HTTP処理 | Jakarta Servlet |
| URLルーティングとREST API | JAX-RS |
| データベース連携 | JPA |
| トランザクション管理 | JTA / EJB |
| 認証・認可 | Jakarta Security |
開発者は「業務ロジック」（勤怠の計算や申請のルールなど）に集中できるようになり、生産性が大きく上がります。
Spring Frameworkとの関係
日本の現場ではSpring Boot（Spring Frameworkを使った軽量なアプリ開発の枠組み）が広く使われており、「Jakarta EEよりSpringのほうが主流では？」と感じる方も多いかもしれません。
実はSpringはもともと、「Java EEが重すぎる」という不満から生まれた代替品です。しかし完全な別物というわけではなく、Springも内部的にはServletやJPAなどJakarta EE由来の仕様を利用しています。
近年はSpring 6（2022年リリース）以降、Spring側もJakarta EE 9+に準拠してjavax.*からjakarta.*に切り替わっています。つまり「Spring vs Jakarta EE」という対立構造ではなく、「Springの土台としてJakarta EEの仕様が活きている」という関係性なのです。
まとめ
- Jakarta EEは企業向け大規模JavaアプリのためのAPI標準仕様の集合体
- Java SEは基盤であり、Jakarta EEはその上に積まれる拡張レイヤー
- Jakarta EEの歴史は「J2EE → Java EE → Jakarta EE」と3段階で進化
- 2017年にOracleからEclipse Foundationへ移管され、商標の都合で2018年に改名
- 2020年のJakarta EE 9でjavax.*からjakarta.*へ「big bang」と呼ばれる一斉パッケージ名変更が発生
- SpringもJakarta EEの仕様を内部で活用しており、両者は対立ではなく共存関係
Jakarta EEの名前と歴史を知っておくと、古い技術書や既存システムに触れたときに戸惑わずに済みます。業務でJavaを扱うエンジニアの方は、ソースコードにjavax.*が出てくるかjakarta.*が出てくるかを意識するだけでも、そのシステムがどの時代の技術で作られているかが見えてきます。ぜひ学習や現場で役立ててください。
参考リソース
- Jakarta EE 公式FAQ（Eclipse Foundation） Jakarta EEの歴史と命名の経緯について公式見解が記載されています。
- Javax to Jakarta Namespace Ecosystem Progress（Eclipse Foundation） javax.*からjakarta.*への移行の進捗と背景の公式解説です。
- Jakarta EE – Wikipedia J2EE時代からの歴史が体系的にまとまっています。
- A Developer’s Guide to Jakarta EE 11（Eclipse Newsroom） Jakarta EEの各バージョンのリリース履歴と特徴がまとめられています。
コメント