Jakarta EEを知る！ オープンソース化されたエンタープライズJavaの現状と今後、バージョン9公開

Jakarta EEは、エンタープライズ分野向けのJavaの開発および実行環境の標準仕様です。Javaプラットフォームの標準仕様には、大きく分けると次の3種類があります。

Java SE

Javaの最も基本となる言語機能とAPI、Java VMなどを含んだプラットフォーム。Java Platform Standard Editionの略称

Jakarta EE（Java EE）

Java SEに対して、大規模なサーバサイド・アプリケーションを開発する機能を付け加えたエンタープライズ分野向けのプラットフォーム。EEはEnterprise Editionの略

Java ME

情報家電やモバイル端末などを対象とした、組み込み機器向けのプラットフォーム。最小限のハードウェアリソースでも動作するようにコンパクトな仕様になっている。MEはMicro Editionの略

Java SEは全てのJavaプラットフォームの基本となるもので、プログラミング言語としてのJavaの基本的な仕様や、各種標準ライブラリ、Java VMを含む実行環境などが提供されます。Jakarta EEを使う場合にも、基本機能としてJava SEが必要です。

Javaの標準仕様とJava SE

Java SEの標準仕様は、コミュニティが主導するJava Community Process（以下、JCP）という仕組みに基づいて策定されます。例えば、2020年5月時点のJava SEの最新バージョンはJava SE 14ですが、この仕様はJCPによって「JSR 389」として決められています。

Java SEのアプリケーションを開発するための開発ツールは一般的にJDK（Java Development Kit）と呼ばれており、現在はOpenJDKプロジェクトによってオープンソースで開発されたものが広く使われています。

つまり、Javaの基本的な仕様はJCPによって決められ、実際の開発はOpenJDKプロジェクトによって行われているというわけです。もっとも、OpenJDKプロジェクトは成果物としてソースコードしか提供しないため、実際には各ベンダ（OracleやIBMなど）がOpenJDKの成果物をもとに独自のJDKを作成して提供する形になっています。

Java EEからJakarta EEへ

Java SEには、サーバサイドで動作する大規模な業務アプリケーションを開発する機能は含まれていません。

例えば銀行のネットバンキングシステムや、コンビニエンスストアのPOSシステム、多数のユーザが利用するインターネットの通販サイトなどといった大規模なシステムを開発するためには、Java SEで提供される機能だけでは力不足なわけです。

そのようなエンタープライズ分野でのニーズに対応したJavaプラットフォームの標準仕様として位置付けられているのが、Jakarta EEです。

Jakarta EEはもともとは「Java EE」という名称で、Java SEと同様にJCPによって仕様が策定されていました。次のセクションで説明する経緯により、開発・保守がオープンソース団体のEclipse Foundationに移管され、名称も「Jakarta EE」に変更されました。

Java EEからJakarta EEに至る経緯

Java EE/Jakarta EEの歴史

エンタープライズ版Javaプラットフォームの最初のバージョンはJ2EE 1.2（Java 2 Platform, Enterprise Edition 1.2）で、1999年にリリースされました。これにはServletやJSP（Java Serer Pages）、JDBCなどといった基本的なサーバサイド技術に加えて、EJB（Enterprise JavaBeans）やJMS（Java Message Service）、JNDI（Java Naming and Directory Interface）など、本格的なエンタープライズアプリケーション開発のための機能が含まれました。

その後、2017年8月にリリースされたJava EE 8までで6度にわたる改定が行われました。J2EE 1.4まではエンタープライズの要件を満たすためにさまざまな機能を取り入れ、その結果として仕様が肥大化して、アプリケーション開発の設定が煩雑になる問題が発生していました。

そこで、Java EE 5ではアノテーションの全面的な導入によって、各種設定を簡略化することに成功しました。続くJava EE 6ではプロファイルの概念が導入され、用途に応じたAPIのサブセットを定義できるようになりました。CDI（Contexts and Dependency Inject）が導入さたのもこのときで、次のJava EE 7ではそれまでのEJB中心のアーキテクチャからCDIへの本格的な移行がスタートしました。

Java EE GuardiansとJava EE 8のリリース

Java EE 7がリリースされて3年後の2016年、Javaコミュニティでは「Java EE Guardians」というプロジェクトが立ち上がります^†。当時はJava EE 8の仕様策定と開発が行われていましたが、その作業がスケジュールから大幅に遅れていたことから、OracleのJava EE 8開発に対する投資が少なくなっているのではないかという懸念が持ち上がっていました。

この状況に対する危機感を表明し、Oracleに改善を促そうという目的で結成されたのがJava EE Guardiansです。この活動には多くの企業や団体、Java開発者が賛同し、結果としてJava EE 8の開発は再び活性化され、翌年のJava EE 8リリースへとつながりました。

当初Java EE 8はクラウドを中心とした新しい時代に適応できるJava EE仕様を目指していましたが、上記のような経緯もあり、Java EE 7の小規模な改訂版という位置付けでリリースされることになりました。

† Java EE Guardiansは、その後もJakarta EEの活動を推進する独立団体「Jakarta EE Ambassadors」として活動が続いています。

Java EE 9の開発中止とEE4Jプロジェクト

Java EE 8のリリースからまもない2017年9月、OracleはJava EE 9以降の開発を中止し、Java EEに関する成果物をオープンソースとして非営利団体に寄贈することを発表しました。その寄贈先としてEclipse Foundationが選ばれ、Java EE資産を移管するプロジェクトとしてEclipse Enterprise for Java（EE4J）が立ち上げられました。

Oracleから寄贈された対象物には、Java EE関連のAPIや参照実装であるGlassFishだけでなく、Technology Compatibility Kit（TCK: 互換性試験キット）などが含まれています。TCKは、Java EEの実装が正しく仕様を満たしていることをテストするツールです。

サードパーティが開発したJavaアプリケーションサーバなどのソフトウェアが「Java EE互換である」と名乗るためには、このTCKによるテストを通過する必要があります。TCKがオープンソースになったということは、互換性の管理も含めてコミュニティに移管されたことを意味しています。

ただし、「Java」の商標は引き続きOracleが所有するため、オープンソース化後には「Java EE」の名称を使い続けることができなくなりました。そこでEclipse Foundationによって投票が行われた結果、「Jakarta EE」という名称になることが決定しました。

この名称の変更に伴い、Java EEに含まれる各種コンポーネントについても、（その多くがJavaの文字列を含むため）Jakarta EE用の名称に変更されています。

EE4JプロジェクトによるJava EE資産の引き継ぎは2019年1月に完了し、2019年9月にJakarta EEの最初のバージョンであるJakarta EE 8がリリースされました。互換実装であるEclipse GlassFish 5.1や、関連するTCKなども同時にリリースされています。

Jakarta EEの基本方針

Eclipse Foundationでは、Jakarta EEプロジェクトを始めるにあたって、その方向性を決めるアンケート調査を行いました。その結果、エンタープライズ市場ではコンテナ、マイクロサービス、そしてマルチクラウドに対応した移植性のサポートが、Jakarta EEに特に求められた要件だということが明らかになりました。

そこでプロジェクトチームは、Jakarta EEが当面のあいだ注力する対象を「動的でスケーラブルな、クラウドネイティブ・アプリケーションの開発」とすることに決定しました。

Java EE 8互換でオープンソースライセンス化

その上で、最初のリリースであるJakarta EE 8は、次のような基本方針に従って開発が行われました。

• Java EE 8仕様と完全な互換性を保つ
• Jakarta EEの仕様策定プロセスに従った透明性のある仕様策定を保証する
• Java EE 8と同じAPIおよびjavadocを含む
• Java EE 8のTCKと完全に互換性があるJakarta EE 8のTCKを、オープンソースライセンスのもとで提供する
• Java EE 8プラットフォーム仕様のインテグレーション要件と同じ内容のJakarta EE 8プラットフォーム仕様を含む
• （サードパーティによる）実装が、Jakarta EE 8仕様との互換性を明確にできるプロセスを提供する

このように、Jakarta EEプロジェクトの最初の目標は、Java EE 8と同一の機能を持ち、ライセンスのみオープンソースライセンスに変更されたエンタープライズJavaプラットフォームをリリースすることでした。

クラウドネイティブ・アプリケーション開発のサポートに向けた機能拡張やAPIの変更については、その後のリリースで段階を踏んで実現していく予定になっています。

クラウドネイティブなJava

クラウドネイティブなJavaとは何か？ なぜ多くの企業にとってクラウドネイティブが重要なのか？ そして、それらの要件に対してJakarta EEテクノロジーがどのように応えるのか？ といった話は「Fulfilling the Vision for Open Source, Cloud Native Java」という文書にまとめられ、無料で公開されています。

クラウドネイティブに向けた直近の活動としては、まずクラウドに必要のないJava EEの既存機能や、逆にクラウドに必要だがまだJava EEに提供されていない機能を洗い出すことが挙げられています。そしてコミュニティベースのオープンなプロセスに従って、これらの機能の短期的・長期的な優先順位を決定し、実装を進めるとのことです。

そして将来的には、Jakarta EEはJava EEから分岐し、クラウド中心のプラットフォームへと進化していくことになります。

Jakarta EE 8の主な新機能

Jakarta EE 8は非常に汎用性の高いプラットフォームになっており、30以上の機能が個別のAPIとして提供されています。ここでは、Java EE 7からJakarta EE 8へのアップデートで強化された主な機能を紹介します。

なお、便宜上Jakarta EE 8と記載していますが、前述のようにJava EE 8でも同じ機能が提供されています。

1. Webコンテナ技術の強化

Webコンテナは、Webアプリケーションを実行するためのコンテナです。主にServlet技術を中心として動作し、クライアントアプリケーションとの間でHTTPなどの通信によるデータ交換を行うことができます。

Servletは、初期のJava EEから提供されており、Web技術の進化に応じて強化されてきたAPIですが、Jakarta EE 8では特に次の2つの機能が追加されました。

• サーバプッシュ通信のサポート
• HTTP Trailerのサポート

サーバプッシュ通信とは、 クライアントからのリクエストに依存せずに、サーバ主体でリソースの送信ができる仕組みであり、HTTP/2で標準化されています。あらかじめ要求されるリソースが予測できるケースで、クライアントからのリクエストを待つことなく送信を開始することが可能なため、通信のオーバーヘッドを減らせるメリットがあります。

HTTP Trailerは、HTTPのリクエストBodyの末尾に、ヘッダと同様の構造で情報を付与できる仕組みです。デジタル署名やメッセージの完全性チェックのためのチェックサムなど、本文の送信後にしか分からない情報を付与したい場合に利用できます。

WebアプリケーションのためのGUIコンポーネントフレームワークであるJakarta Server Faces（元のJSF）も強化されました。

• <f:websocket>タグによるWebSocketのサポート
• <f:validateWholeBean>タグによるBean Validationのサポート
• CDI互換の@ManagedPropertyアノテーションの追加
• ELを使った拡張されたコンポーネント検索フレームワークの提供

WebSocketは、サーバとブラウザ間で対話的な双方向通信を低いオーバーヘッドで行うことができる技術です。

Bean Validationは、JavaBeansコンポーネントに対する入力値を検証することで、不正な入力を未然に防ぐためのAPIです。このAPIもJava EE 8/Jakarta EE 8で拡張され、Date-Time APIなどといったJava SE 8の新機能のサポートや、ビルトイン制約の追加などが行われています。

2. Webサービス技術のサポート強化

Jakarta EE 8には、Webサービス向けのAPIとして、RESTful WebサービスおよびJSONデータフォーマットをサポートするAPIが強化されています。

まず、RESTful Webサービスについては、Jakarta RESTful Web Serviceに次のような新機能が追加されました。

• リアクティブクライアント用APIの提供
• Server-Sent Eventのサポートを強化し、text/event-streamメディアタイプのサポートを追加
• Jakarta JSON Bindingオブジェクトのサポート
• CDI、Servlet、Bean Validationテクノロジーとの統合を改善

JSONデータフォーマットの取り扱いについては、Jakarta JSON ProcessingとJakarta JSON Bindingという2つのAPIによってサポートされます。

JSON ProcessingはJava EE 7で追加されたものですが、Java EE 8／Jakarta EE 8ではJSON PointerやJSON Patch、JSON Merge Patchといったドキュメント操作の新しい構文や、処理ルールを定義するフォーマットが追加されました。また、Java SE 8で導入されたStream APIを利用するため、JSON Collectorsと呼ばれるヘルパークラス／メソッドが追加されています。

JSON Bindingの方は今回から新しく追加されたAPIで、JSONメッセージとJavaオブジェクトのバインディングを行います。これによって、JSON形式のデータとJavaオブジェクトとの相互変換が容易に実現できるようになります。日常的なシナリオに適したデフォルトのマッピングがあらかじめ用意されているほか、デフォルト設定のオーバーライドやアノテーションの利用によって、独自のマッピングを作るとこもできます。

3. CDIの機能強化

CDI（Contexts and Dependency Injection）は、現在のJava EEおよびJakarta EEの中核となる技術です。Jakarta EEのアプリケーション開発では、CDIが依存関係を管理するオブジェクトに対してビジネスロジックを実装します。オブジェクトとしては、CDIが直接管理するCDI Beanと、EJBコンテナによって管理されるEnterprise Beanのいずれかを使用します。

Jakarta EEのCDI機能は、Dependency Injectionを定義するJakarta Dependency Injectionと、これを拡張したJakarta Contexts and Dependency Injectionによって提供されます。

Jakarta EE 8では従来のCDIに対して、主に次の点が強化されています。

• Java SE 8でCDIコンテナをブートストラップするAPIの追加
• CDIオブジェクトを動的に定義および変更する設定インタフェースの追加
• アノテーションのインスタンス作成を容易にするなどの機能を持った組込みアノテーションリテラルの追加
• 特定のイベントのオブザーバーメソッドが呼び出される順序を指定できるObserver Method Orderingのサポート
• 非同期でのイベント発生のサポート

4. セキュリティ機能の強化

従来のJava EEでは、低水準のセキュリティ機能を提供するAPIとしてJakarta AuthorizationとJakarta Authenticationが用意されていました。Jakarta EE 8では、それに加えてより高水準のセキュリティ機能を提供するJakarta Securityが追加されました。

Jakarta Securityでは大きく分けて、以下の3つのコンポーネントが用意されています。

• Authentication Mechanism
• Identity Store
• SecurityContext

Authentication Mechanismは、認証およびその後の制御フローを管理するコンポーネントです。BASIC認証などのあらかじめ用意された認証メカニズムを利用できるほか、HttpAuthenticationMechanismインターフェースを継承して独自のカスタム認証メカニズムを作成することもできます。

Identity Storeは、ユーザ資格情報や、グループ情報、呼び出し側の資格情報などを検証し、安全に保管する機能を提供するAPIです。独自のIdentity Storeを実装するほかに、組み込みのLDAPやデータベースストアを使用することができます。

SecurityContextは、上記のセキュリティ機能に対してアプリケーションのコードから統一的にアクセスできるようにする仕組みです。WebコンテナとEJBコンテナの両方の認証メカニズムに対して、一貫した方法でアクセスできるようにしている点が大きな特徴です。

Jakarta EE 8のチュートリアル

こういったJakarta EE 8の機能を網羅的にカバーしたチュートリアルが、EE4Jプロジェクトから提供されています。

The Jakarta EE 8 Tutorial

各APIの詳細について知りたい場合には、このチュートリアルを参照するといいでしょう。

既存のシステムへの影響と対策

Java EEがJakarta EEになったことで、既存のシステムにはどのような影響が生じるでしょうか？

まず大前提として、Java EEの開発が移管されたとしても、現在使用しているJava EEの実装がすぐ使えなくなるわけではありません。現行のJava EEのサポート期限はそれぞれの実装を提供しているベンダに依存するため、各ベンダからサポートが提供され続ける限り、焦って移行しなければならないということはないでしょう。

その上で、現在Java EE 7以前で動作しているシステムがある場合、移行先としてJava EE 8とJakarta EE 8のどちらを選ぶかは検討が必要かもしれません。とはいえ、この2つは実際のところ機能的に同一なので、どちらを選んでも大きな違いは生じないはずです。これについては新規でプロジェクトを開始する場合も同様ですが、Jakarta EE 9への移行も踏まえた長期的な視点で考えれば、Jakarta EE 8の方が適していると言えるでしょう。

1つだけ気を付けなければならない点として、前述の商標の問題によって、Jakarta EEではAPIの名称が変更されていることが挙げられます。ただし何度も強調しているように、名称が変わったとしても、内部の機能はパッケージ名も含めてJava EE 8で提供されているものとまったく同等であり、完全な互換性が保持されているため、現実的に問題になることはないでしょう。

Java EE 8とJakarta EE 8のAPIの名称およびバージョンの違い

次の表は、Java EE 8とJakarta EE 8のAPIの名称およびバージョンの違いをまとめたものです（Jakarta EE Platform 8 Specification Documentより抜粋）。

APIの名称から「Java」の文字が削除されて「Jakarta」に置き換わっていることがわかります。同時に、Jakartaの文字は名称の先頭に付けるなど、命名規則が統一されました。また「Enterprise JavaBeans」のようにもともとJavaの文字が含まれていなかったものについても、Jakartaの文字が付加されるようになりました。

いくつかのAPIについてはバージョンが変わっていますが、いずれも機能的には同等で完全に互換性があるものになっています。

Java EE 8とJakarta EE 8のAPI対応表

Java SE 8から移管されたAPI

Java 11以降のバージョンで動作するJakarta EE 8実装を使用したい場合には、もう一点注意しなければならないことがあります。

次の表に挙げたAPIはJava EE 8およびJakarta EE 8で使用できますが、これらはJava SE 8に含まれるものであり、厳密にはJava EE／Jakarta EEの仕様に含まれていません。これらのAPIも、Java EEの他のAPIと同様に、Eclipse Foundationに寄贈されています。

Java EE 8とJakarta EE 8のAPI対応表2

Java SE 8をベースプラットフォームとしてJava EE 8／Jakarta EE 8を動かす場合には問題ありませんが、Java SE側の仕様変更によって、Java SE 11以降ではこれらのAPIが削除されて使えなくなっています。

そこで、Java SE 11以降で動作するJakarta EE 8実装については、これらのAPIを仕様の一部として含めてよいことになりました。もしベースプラットフォームとしてJava SE 11以降を使用する場合には、名称の変更と同時に、Jakarta EE 8の実装がこれらのAPIをサポートしていることを確認しましょう。

新バージョン「Jakarta EE 9」のリリースプラン

Jakarta EE 8の次のバージョンとなるJakarta EE 9は、2020年6月23日に最初の公開版であるMilestone 1がリリースされており、最終的な完成版のリリースは2020年9月に予定されています。

Jakarta EE 9は、オープンソース化されてから初めての機能変更を含むバージョンということになります。とはいえ、各ベンダが関連するツールなどを素早く提供できるようにする目的から、機能面での変更は最小限に収める方針で仕様策定が行われました。

Jakarta EE 9のリリースプランの詳細は、次のページにまとめられています。

Jakarta EE 9 Release Plan - Jakarta EE Platform Project

パッケージ名がjavaxからjakartaに変更

最も影響が大きな変更点としては、パッケージ名が変わったことが挙げられます。

Java EEには、パッケージ名がjavaxから始まるコンポーネントが多数含まれています。しかし、前述した「Java」の商標問題に関連して、Jakarta EEではパッケージの名前空間に「javax」という文字を使うことができなくなりました。

厳密には、javaxのパッケージ名を残すことはできますが、それは各コンポーネントを現状のまま変更せずに使う場合に限られます。Jakarta EEで機能拡張を含めた何らかの変更を加える場合には、パッケージ名を別のものに変更する必要があります。

そこで、Jakarta EE 9の各APIではパッケージの名前空間として、代わりにjakartaを使用することを決定しました。

この変更はJakarta EE 9で一斉に行われたため、Java EE 8／Jakarta EE 8以前をターゲットとして作られた全てのアプリケーションは、そのままではJakarta EE 9で動作しません。後方互換性が失われたことになりますが、既存プロジェクトに対する影響を少なくするため、移行のツールを提供するなどのサポートが予定されています。

追加されるAPI

APIに関してもいくつかの変更があります。まず、次のAPIが新たに追加されています。

• Jakarta Activation

このAPIはもともとJava SE 8で提供されていたものですが、Java SE 11でプラットフォーム仕様から削除されました。Jakarta EE 9はJava SE 11以降が動作要件となっていますが、このAPIはエンタープライズJavaでは引き続き必要なものであるため、今後はJakarta EEのプラットフォーム仕様として含まれることになりました。

同様の理由で、以下のAPIがオプションとしてJakarta EE 9に追加されました。

• Jakarta XML Binding（JAXB）
• Jakarta XML Web Services（JAX-WS）
• Jakarta Web Services Metadata
• Jakarta SOAP with Attachments

削除されるAPI

一方で、次のAPIはJakarta EE 9で削除されました。

• Jakarta XML Registries
• Jakarta XML RPC（JAX-RPC）
• Jakarta Deployment
• Jakarta Management
• EJBのDistributed Interoperability（EJB 3.2仕様のChapter 10）

これらのAPIは現時点ですでにほとんど使用されていないため、削除することによってJakarta EEの実装を提供するベンダの負担を少なくする目的があります。

同様の理由で、以下のAPIは必須ではなくオプションになりました。

• Jakarta Enterprise Beans 2.xのAPI群
• Jakarta Enterprise Web Services

Jakarta EE 9 Milestone 1の詳細

Jakarta EEには、全てのAPIが含まれたフル機能の「Full Platform」と、Webアプリケーション開発向けのAPIだけを集めた「Web Profile」の2種類があります。

6月23日にリリースされたMilestone 1には、内容としては次のものが含まれています。

• Web Profileの“ほとんど”の仕様
• Web Profileの“全て”のAPI
• Web Profileの“多く”のTCK
• 互換実装のプレビュー版（GlassFish 6.0.0 M1、Open Liberty 20.0.0.7 Beta、Tomcat 10.0 M5など）
• ベースプラットフォームのバージョンはJava 8

Web Profileは、Webアプリケーション開発に特化した機能しか使えない代わりに、Full Platformよりも小型で軽量という強みがあります。

Jakarta EE 9 Milestone 1は、まずこのWeb Profileについて十分な機能の提供を目指したリリースとなっています。

Jakarta EE 9から先へ

9月に予定されている最終リリースには、当然ながらフル機能のAPIが含まれます。ベースプラットフォームのバージョンは、前述のとおりJava 8ではなくJava 11になります。

Jakarta EEプロジェクトでは、最終リリースに向けてAPIを8つのグループに分類し、Wave 0からWave 7の8段階に分けて順番に提供していくことを計画しています。具体的にどのAPIがどのWaveに含まれるかは、先ほど紹介したリリースプランの後半に掲載されています。各Waveごとのスケジュールについては、次のページを参照してください。

Jakarta EE 9 (under development) - Jakarta EE 9 schedule

Jakarta EE 10以降の仕様については、まだ議論が続いている最中です。当初の目標として挙げられていた「クラウドネイティブなJavaアプリケーション開発のためのプラッフォーム」に向けて本格的に舵を切っていくことになるでしょう。

今後のリリースモデルなどについても、Jakarta EE 10から決定・適用されていく予定となっています。

杉山 貴章（すぎやま・たかあき） zinbe

有限会社オングスにて、Javaを中心としたソフトウェア開発や、プログラミング関連書籍の執筆、IT系の解説記事やニュース記事の執筆などを手がけている。そのかたわら、専門学校の非常勤講師としてプログラミングやソフトウェア開発の基礎などを教えている。著書に『Javaアルゴリズム＋データ構造完全制覇』など。

【修正履歴】ご指摘により一部誤記を修正しました。（2020年7月9日10時）