X

A blog about Oracle Technology Network Japan

Java EEからJakarta EEへ

Guest Author

※本記事は、Arjan Tijmsによる"Transition from Java EE to Jakarta EE"を翻訳したものです。


何が起きたのか、何を知っておくべきか

 

著者:Arjan Tijms

2020年2月27日

 

Java EEは、間違いなく、サーバー・サイドJavaで特によく知られたフレームワークの1つです。実質的に、業界がJavaをサーバーで使用するという方向に勢いをつけたのはJava EEです。Java EEは、Javaがまさに始動したばかりである1996年のKiva Enterprise Server(GlassFish)やTengahアプリケーション・サーバー(Oracle WebLogic Serverの前身)にまでさかのぼります。なお、ここで使われているTengahという言葉は、インドネシアのジャワ島の中部にある行政区域を指しています。

Java EEは、かつてJ2EE(Java 2 Enterprise Edition)と呼ばれていました。その認知度をもっとも高めているのは、Java Servlet仕様と、この仕様を実装するサーバー(TomcatやJettyなど)でしょう。多くの場合、このようなサーバーはサーブレット・コンテナと呼ばれます。代わりとなる選択肢もありますが、多くのサーバー・アプリケーションやサードパーティ・フレームワークがJava Servlet仕様に基づいています。その後のJava EEは、この仕様に加えて、永続化(Java Persistence API(JPA)、大部分はHibernate経由)、REST(JAX-RS)、WebSocketの仕様、さらにトランザクション(Java Transaction API(JTA)、大部分はJPAで内部的に使用)、検証(Bean Validation)、JSON(JSON-PおよびJSON-B)といった多数の細かな仕様群で知られるようになりました。

実際には、Java EEアプリケーションに分類されることは考えにくいアプリケーションでも、さまざまなJava EE APIが使われている場合があります。

アプリケーション・サーバーでは、以前からJava EEの完全な実装が使われていますが、こちらも大きな成功を収めています。JBoss/WildFly、GlassFish/Payara、そして直近のOpen Liberty(WebSphereの後継)はすべてよく知られています。

さらに、アプリケーション・サーバーでもサーブレット・コンテナでもないにもかかわらず、さまざまなJava EE APIをすぐに使用できる製品群もあります。たとえば、Quarkus(Contexts and Dependency Injection(CDI)、JAX-RS、JPA)、Helidon(CDI、JAX-RS、JPA、JTA)、KumuluzEE(CDI、JAX-RS、JPA、Servlet、JavaServer Faces (JSF)、WebSocket、Bean Validation、JSON-P)、Piranha(CDI、JAX-RS、Java EE Security、Expression Language(EL))です。

最後に、MicroProfileと呼ばれる、Java EEから派生したプラットフォームもあります。MicroProfileは、CDI、JAX-RS、JSONなどのJava EE APIに直接的に依存しています。これらすべてによって、Java EE APIは多くのユーザーにとって欠かせないものとなっています。


Java EEに何が起こっているのか

厳密な意味でのJava EEの最新リリースは、2017年8月のJava EE 8でした。このリリースは範囲が限定されたものでしたが、Java EE Securityなどの重要な機能も含まれていました。その年のうちに、オラクルはJava EEをオープンソース団体に完全に移管することを決めました。そして、Java EEパートナーのRed HatとIBMの協力のもと、完全なリファレンス実装およびTechnology Compatibility Kit(TCK)とともに、Java EEはEclipse Foundationに移管されることに決まりました。

この移管に伴って大量の作業が発生することから、プロセスは3つのステージに分割されました。

ステージ1:APIおよび実装コードの移管、検証済みビルドのリリース。最初のステージは、Eclipse Enterprise for Java(EE4J)と呼ばれるトップレベルの新プロジェクトをEclipseに作ることでした。EE4Jプロジェクトと、このプロジェクトに関連するGitHubの組織eclipse-ee4jzは、仕様プロジェクトと実装プロジェクトの両方のホームです。EE4Jを、Java EEの新しいブランド名であるJakarta EEと混同しないでください。Jakarta EEは、この数か月後にコミュニティが選んだ名前です。

github.com/javaeeにあるオラクルのリポジトリからすべての既存ソース・コードを実際に移管する前に、すべてのコードについて法的問題を解消する必要がありました。これは何より、問題となる可能性がある部分を削除しなければならないということを意味しました。数百万行ものコードを調べるという作業が、簡単なものでないことは明らかでした。過去のコードすべてについても同様に法的問題を解消するということは不可能でした。そのため、まず特筆すべきなのは、リリースされた最新バージョンのコードのみが移管されたということです。たとえば、JSF 2.3は、マスター・ブランチからのスナップショットとして移管されました。JSF 2.2およびそれ以前のバージョンは元々の場所に置かれたままで、Eclipse Foundationによるメンテナンスやサポートは行われていません。

ソース・コードの移管後に、Eclipseのビルド・サーバーを使ってすべてのコードがビルドされ、その結果がMavenリポジトリにステージングされました。APIのJARファイルは、Eclipseが作成したビルド・アーティファクトであることを示すため、MavenのグループIDがjavax.*からjakarta.*に変更されました。そこからGlassFishの新しいビルドが生成され、そのビルドに対してオリジナルのJava EE 8 TCKが実行されました。このビルドがTCKテストに合格し、すべてのコードの移管が成功したことが証明された後に、GlassFish 5.1としてリリースされました。

ところで、グループIDがJakartaになって最初のリリースのAPIは、Jakarta EE 8認定ではなく、Java EE 8認定です。たとえば、jakarta.faces:jakarta.faces-api:2.3.1はjavax.faces:javax.faces-api:2.3と同じもので、両方ともJava EE 8認定です。しかし、前者はgithub.com/eclipse-ee4jからビルドされ、後者はgithub.com/javaeeからビルドされています。

ステージ2:TCKコードの移管、新しい仕様プロセスの立ち上げ、新しい用語の定義、新ブランド版ビルドのリリース。第2ステージは、TCKを移管し、そこからJakarta EE 8認定の新しいバイナリをビルドすることでした。新しい認定プロセスであるJakarta EE Specification Process(JESP)も立ち上がりました。また、新しい仕様ライセンスであるEclipse Foundation Technology Compatibility Kitライセンスも作成されました。

このステージでは、シンプルで一貫性を高めた新しい名前がすべての仕様に付けられました。新しい名前は、すべてJakartaで始まり、簡単に仕様を説明した言葉が続きます。一貫性のないつなぎの言葉(アーキテクチャ、API、サービスなど)は入らないようになっています。

新旧の用語を表1に示します。

Old Java EE 8 terms compared to new Jakarta EE 8 terms

表1:古いJava EE 8の用語と新しいJakarta EE 8の用語の比較

このステージでは、新しい用語を反映させるために、すべてのAPIのJavadocが更新されました。また、生成されたAPI JARファイルのライセンスも新しくなり、移管されたTCKソース・コードからビルドした新しいブランドのTCKを使ってGlassFish 5.1でテストが行われました。これはすべて、新しいJESP仕様のプロセスに従ったものです。

生成されたすべてのAPI JARファイルは、ほぼ空のプレースホルダ仕様ドキュメントとともにリリースされました。このファイルとドキュメントを組み合わせたものが、Jakarta EE 8を構成しています。

個々のJARファイルでは、厳密に言って同じAPIが、このステージで3回目のリリースを迎えたことになります。MavenのグループIDにJakartaを使用した2回目のリリースであり、Jakarta EE認定となった初めてのリリースです。表2にJSF/Jakarta Facesの例を示します。
 

Example showing the JAR files for JSF and Jakarta Faces

表2:JSFおよびJakarta FacesのJARファイルの例(画像を拡大)

ここで注目すべき点があと2つあります。

1つ目は、Jakarta EE 8には対応するGlassFishリリースがなかったことです。ただし、GlassFish 5.1は既存のJava EE 8認定であることに加え、Jakarta EE 8認定でもありました。

2つ目は、前述のように、Jakarta EE 8は実質的に空の仕様ドキュメントとともにリリースされたことです。仕様ドキュメントの法的問題を解消して移管するために必要な時間が膨大で、Jakarta EE 8のリリースには到底間に合わなかったというのがその理由です。現在のところ、このテクノロジーのユーザー(実装者以外)は、対応するJava EE 8ドキュメントの評価版を読むことができます。

Jakarta EEバージョンのAPIへの更新は、今後予定されている大きな変更に備えてユーザーが踏み出せる小さな第一歩です。Mavenプロジェクトでは、この更新を非常に簡単に行うことができます。次の記述を、

<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-api</artifactId>
    <version>8.0</version>
    <scope>provided</scope>
</dependency>

次のように置き換えます。

<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>8.0.0</version>
    <scope>provided</scope>
</dependency>

または、個々の依存性を使用している場合、次のような記述を

<dependency>
    <groupId>javax.faces</groupId>
    <artifactId>javax.faces-api</artifactId>
    <version>2.3</version>
    <scope>provided</scope>
</dependency>

次のように置き換えます。

<dependency>
    <groupId>jakarta.faces</groupId>
    <artifactId>jakarta.faces-api</artifactId>
    <version>2.3.2</version>
    <scope>provided</scope>
</dependency>

APIは本質的に同じであるため、この更新を行ってもほとんど問題はないはずです。ただし、Mavenでは、一方が他方より新しいと2つの依存性を関連付けることはしないという点に注意してください。

Mavenにとっては、まったく異なる2つの依存性が存在することになります。そのため、Mavenは関連性を何も知らずにその両方をインクルードします。たとえば、トップレベルの依存性が推移的にJava EE依存性を取り込むような場合、二重インクルードが起きるかもしれません。Jakartaに更新する前であれば、推移的に導入されるjavax.faces:javax.faces-api:2.2はトップレベルのjavax.faces:javax.faces-api:2.3などで上書きされるでしょう。

トップレベルの依存性がjakarta.faces:jakarta.faces-api:2.3.2に変更された場合、2.2の依存性は上書きされなくなり、Mavenは両方を使用することになるため、さまざまな問題につながります。推移的なインクルードを更新できない場合、通常は除外を使用してこの問題を修正することができます。たとえば、次のようにします。

<dependency>
    <groupId>com.example</groupId>
    <artifactId>foo</artifactId>
    <scope>provided</scope>
    <exclusions>
        <exclusion>
            <groupId>javax.faces</groupId>
            <artifactId>javax.faces-api</artifactId>
         </exclusion>
     </exclusions>
 </dependency>


 
これで、プロセスの最後のステップにたどり着きました。

ステージ3:仕様ドキュメントの移管および更新、余分な仕様の削除、APIパッケージ名の変更、JDK 11のリリース。現在は移管の最後のステップにあり、今年中に終わる予定となっています。このステージには、仕様ドキュメントのソース・コード(ほとんどがAsciiDoc)の移管が含まれています。仕様ドキュメントのソース・コードは、APIコード、実装コード、TCKコードに続いて移管されることになる、最後のアーティファクトです。APIのJavadocと同じように、仕様ドキュメントも新しい用語を使って更新される予定です。

しかし、このステージでもっとも影響の大きい項目は、すべてのJava APIパッケージ名をjavax.*からjakarta.*に変更することです。たとえば、javax.faces.context.FacesContextはjakarta.faces.context.FacesContextになります。このパッケージ名変更は、結果として既存アプリケーションのコードの更新が必要になるため、重大なアップデートです。

Java EE 8のリリースからかなりの時間が経過していることを考慮すれば、Jakarta EE 9ではJDK 11の公式サポートが必要でしょう。しかし、JDK 8は今でも重要性が高いため、APIはJDK 8のままです。現実的には、APIはJDK 8のソース・コード・レベルでコンパイルできる必要があるものの、実装はJDK 11で実行するTCKに合格しなければならないという意味になります。

JDK 11では、それまでにJava EEからJava SEに移動したいくつかの仕様が削除されています。そのため、今度はそれらの仕様を復帰させることになります。Jakarta Activationは必須仕様(具体的には、Jakarta Mailに必須の依存性であるため)としてJakarta EEに追加されていますが、Jakarta XML Binding、Jakarta XML Web Services、Web Services Metadata、SOAP with Attachmentsは、オプション仕様として追加されています。

Jakarta Enterprise Beans(旧称EJB)は、サイズが再度削減される予定です。EJB 3.1では、エンティティBean(EJB Query Languageを含む)とJava API for XML-based RPC(JAX-RPC)エンドポイントが削除されました。そして今回は、EJB 2.1 APIグループ(javax.ejb.EJBHomeなど)と、いわゆる分散相互運用性が削除されます。

さらに、Deployment仕様(JSR 88)とManagement仕様(JSR 77)も削除されます。JSR 88はJava EE 8ですでにオプションでした。JSR 77は、かつてメジャー・アップデートが予定されていましたが、実現しませんでした。JAX-RPCは、かなり以前にJAX-WSに取って代わられ、Java EE 8ですでにオプションとなっていました。今回はこのJAX-RPCもついに削除されることになります。さらに、同様にJava EE 8ですでにオプションになっていたXML Registriesも削除されます。

 

JSF/Jakarta example updated for Jakarta EE 9

表3は、Jakarta EE 9で再度更新されるJSF/Jakarta Facesの例を示しています。Java EE 8に関連する変更は太字になっています。最後の行は不確定なものであり、まだ変更される可能性があります(ただし、その可能性は低いはずです)。

表3:Jakarta EE 9で更新されるJSF/Jakarta Facesの例(画像を拡大)


まとめ

Jakarta EE 9のリリースと、おそらくはすべての仕様ドキュメントの移管および更新が完了したら、Java EE 8の移管が完了したと見なされます。その時点で、Java EEに関連するすべてのものがEclipse Foundationに移管され、新しいブランドに更新されていることになります。

機能的に見れば、Jakarta EE 9はまだ本質的にJava EE 8と同じです。そのため、純粋に機能的な見方をすれば、Jakarta EE 8にもJakarta EE 9にもユーザーが更新したくなるような特段の魅力はありません。しかし、これらのリリースの目的は、コミュニティやエコシステム(たとえば、ツールやライブラリのベンダー)にアプリケーションや製品の準備をする機会を与えることにあります。新機能が登場する最初のバージョンは、Jakarta EE 10になるでしょう。表4に、リリースとその日程を示します(*印が付いているのは暫定的な予定です)。
 

Release and release dates

表4:リリースとその日程
 


Raoul-Gabriel Urma

Arjan Tijms:JSF(JSR 372)およびSecurity API(JSR 375)で専門家グループのメンバーを務めた。現在はJakarta Security、Jakarta Authentication、Jakarta Authorization、Jakarta Faces、Jakarta Expression Languageなど、多くのJakartaプロジェクトでプロジェクト・リードを担当。2015年のDuke's Choice Awardを受賞した、JSF用の人気ライブラリOmniFacesの共同作成者で、2冊の書籍『The Definitive Guide to JSF』と『Pro CDI 2 in Java EE 8』の著者でもある。オランダのライデン大学でコンピュータ・サイエンスの理学修士号を取得している。Twitterのフォローは@arjan_tijmsから。

 
 

 

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.