Jakarta EE 10で新しくなった点(What’s new in Jakarta EE 10) の勝手翻訳

この記事は以下のブログの4月22日時点の勝手翻訳です。意訳も含みますし、元のブログは変更があり次第どんどん更新すると言ってるのでご注意ください。

www.mastertheboss.com


Jakarta EE 10 は、"jakarta" 名前空間の更新以来、Jakarta EEの最初のメジャーリリースです。多くのコンポーネント仕様はAPIの実装に反映されるメジャーまたはマイナーバージョンが更新されています。この記事では次の新しいメジャーリリースから何が期待できるかを学びましょう。

プロジェクトの状況

最初に、 Jakarta EE 10の進行状況はGitHub上の進行状況ボードで追跡できます:

https://github.com/orgs/eclipse-ee4j/projects/21

リリースされると、以下のように包括的な依存関係を含めることができるようになります。

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

JakartaEE10を実行するための要件

Java SE 11Jakarta EE互換の実装でサポートされる最小のバージョンのランタイムになります。

利用可能なプロファイル:

Jakarta EE 10では次のプロファイルを使用できます。

  • Full Platform Profile:Jakarta EE APIのフルセットを必要とするエンタープライズアプリケーションの開発者向けに設計されたプロファイルです。
  • Web Profile:Jakarta EE APIのすべてを必要としない開発者向けに設計された、Webテクノロジーが含まれているFull Platform Profileの一部で構成されるプロファイルです。
  • Core Profile:この新しいプロファイルには、マイクロサービスと事前コンパイルに適したより小さなランタイムを対象とした一連の Jakarta EE 仕様が含まれています。

削除されたか非推奨になったAPI

次の2つの機能には"削除済み"もしくは"非推奨"のタグが付けられます。(正確な用語やメカニズムは未決定)

EJBエンティティBean(CMPおよびBMP) 埋め込み可能なEJBコンテナ

したがって、EJB 3.0以降のAPI(javax.ejb.Entityなど)で作成されたアプリケーションは、 Jakarta Persistence APIjakarta.persistence)の機能を使用して永続化エンティティをモデル化する必要があります。

最後に仕様のバージョン、プロファイル、必須かどうかを含んだJakarta EE 10 仕様の一覧を示します。

仕様 プロファイル 必須でないかどうか(Yなら必須でない)
Jakarta Activation 2.1 Full Profile N
Jakarta Annotations 2.1 Web Profile N
Jakarta Authentication 3.0 Web Profile N
Jakarta Authorization 2.1 Full Profile N
Jakarta Batch 2.1 Full Profile N
Jakarta Bean Validation 3.0 Web Profile N
Jakarta Concurrency 3.0 Web Profile N
Jakarta Connectors 2.1 Full Profile N
Jakarta Contexts and Dependency Injection 4.0 Full Profile N
Jakarta Debugging Support for Other Languages 2.0 Web Profile N
Jakarta Dependency Injection 2.0 Web Profile N
Jakarta Enterprise Beans 4.0 Full Profile N
Jakarta Enterprise Beans 4.0 Lite Web Profile N
Jakarta Enterprise Web Services 2.0 Full Profile Y
Jakarta Expression Language 5.0 Web Profile N
Jakarta Interceptors 2.1 Web Profile N
Jakarta JSON Binding 3.0 Web Profile N
Jakarta JSON Processing 2.1 Web Profile N
Jakarta Mail 2.1 Full Profile N
Jakarta Managed Beans 2.0 Web Profile N
Jakarta Messaging 3.1 Full Profile N
Jakarta Persistence 3.1 Web Profile N
Jakarta RESTful Web Services 3.1 Web Profile N
Jakarta Security 3.0 Web Profile N
Jakarta Server Faces 4.0 Web Profile N
Jakarta Server Pages 3.1 Web Profile N
Jakarta Servlet 6.0 Web Profile N
Jakarta SOAP with Attachments 3.0 Full Profile Y
Jakarta Standard Tag Library 3.0 Web Profile N
Jakarta Transactions 2.0 Web Profile N
Jakarta WebSocket 2.1 Web Profile N
Jakarta XML Binding 4.0 Full Profile Y
Jakarta XML Web Services 4.0 Full Profile Y

Jakarta EE Platform
Jakarta EE Platform

※画像は元ブログより

主要なAPIアップグレード:

仕様はまだ策定中です。ただし、Jakarta EE 10で期待できる主なハイライトのいくつかをここに一覧化します。

Jakarta Persistence 3.1

  • java.uti.UUID の追加。単純な主キー、複合主キーの両方でフィールドまたはプロパティとして使用できるようになりました。
  • クエリ言語の新しい数値関数
    • CEILING:引数の上限を返します。
    • EXP:引数の指数を返します。
    • FLOOR:引数のフロアを返します。
    • LN:引数の自然対数を返します。
    • POWER:最初の引数を2番目の引数の累乗で返します。
    • ROUND:2番目の引数で指定された小数点以下の桁数に丸められた最初の引数を返します。
    • SIGN:引数の符号を返します。
  • クエリ言語の新しい日付関数
    • LOCAL DATE:データベースサーバーによって定義された現在のローカル日付を返します。
    • LOCAL DATETIME:データベースサーバーによって定義された現在のローカル日時を返します
    • LOCAL TIME:データベースサーバーによって定義された現在のローカル時間を返します。
  • EXTRACT関数のサポート:EXTRACT関数で特定の日付から数値部分を抽出でき、単一のフィールドのみを取得できます。

Jakarta Servlet 6.0

※訳者注:Servlet単独について知りたい場合は記事としてはこっちの方がよさそう。 Top 5 things to know about the Jakarta Servlet 6.0 API release - Coffee Talk: Java, News, Stories and Opinions

  • 非推奨になっていたメソッドの削除
  • Servlet のイミュータブルなrequest/responseのラッパー: 開発者は、持続性のある不変のリクエストとレスポンスを実装することができるようになりました。他のスレッドによるリクエストメソッドの呼び出しと、 リクエストが Servlet コンテナを伝搬する際に必要となる変更との間に競合が発生するからです。
  • URIのセキュリティ保護機能を搭載:現在ではリクエスURIが複数の制約付きURLパターンにマッチするとき、リクエストに適用される制約は、最もよくマッチするURLパターンに関連付けられたものになります。しかしながら、制約付きURLパターンにマッチしないリクエスURIには、 保護要件は適用されません。
  • Cookieの追加属性 : Cookieに自由に属性を追加できるようになります。

Jakarta RESTful Web Services 3.1

このトピックの詳細については、こちらの記事を確認してください: Getting started with Jakarta RESTful Services

  • Java SE Bootstrap APIJAX-RSは、Java SE単独でも動作します。しかし、純粋なJavaSEでJAX-RSサーバーアプリケーションを起動する方法は仕様化されていません。ベンダーロックインを取り除くために、純粋なJavaSE環境でJAX-RSサーバーアプリケーションを起動する方法をベンダーに依存しないAPIで仕様として定義することを提案したいと思います。
  • マルチパートメディアタイプのサポートJakarta EE 仕様はマルチパート/フォームの特定のサポートを提供していませんでした。MultiPartフォームはベンダー固有のアノテーションで実装され、これらの拡張機能に依存するコードは移植できなくなりました。(jersey では@FormDataParam、CXFでは @Multipart)multipart/form-dataメディアタイプを仕様に追加すると、リクエストが複数のエンティティ(パーツ)を単一のエンティティとして送信できるようになります。各部分には、独自のヘッダー、メディアタイプ、およびコンテンツが含まれています。
  • JSON-Bとのより良い連携:アプリケーション提供のJSON-Bクラスの実装提供のエンティティプロバイダーはアプリケーションが提供するコンテキストリゾルバーによって提供されるJsonbインスタンスを使用する必要があります。 [contextprovider]を参照してください。アプリケーションが特定のタイプのJsonbインスタンスを提供しない場合は実装提供のエンティティプロバイダーはjsonbインスタンスの代わりに独自のデフォルトコンテキストを使用する必要があります。
  • プロバイダー拡張機能の自動ロードJavaのServiceLoader APIでマーカーインターフェイスを宣言するだけで、あらゆる種類のJAX-RSコンポーネントを強制的に自動ロードされるコンポーネントに変換する宣言型の方法が追加されます。実際には、提案されたメカニズムは実際にはコンポーネントインスタンス化せずに宣言されたクラスを検出してJAX-RS構成に登録するだけなので、既存のJAX-RSコンポーネントのライフサイクルとスコープが適用されます。
  • CDIとの整合性を高めるための準備としての@Contextの非推奨

Jakarta Server Faces 4.0

このリリースの目標はいくつかの新しい拡張機能MyFacesおよびPrimefacesの実装から着想を得たもの)を含めることです。同時に、非推奨のものを削除し、CDIへの移行を促進します。

  • プログラムでFaceletsを作成するための新しいAPI:現在Faceletsで行われているようなXMLを使用してビューを作成するのではなく、Javaでビューを作成するためのファーストクラスのサポート。
  • 新しい自動拡張なしマッピングorg.apache.myfaces.AUTOMATIC_EXTENSIONLESS_MAPPING が仕様化されました。
  • アノテーション@ClientWindowScoped の追加:PrimefacesのネイティブClientWindow実装と同様の方法でネイティブClientWindow実装が追加されます。
  • カスタムCookie属性のサポート:ExternalContext#addResponseCookie() のSameSiteなど
  • FacesContext#getLifecycleの追加:アプリケーション全体のフェーズリスナーをプログラムで追加および削除する場合に役立ちます。
  • 非推奨だったものの削除JSPサポートやネイティブのマネージドBean(@ManagedBeanおよびその他、CDIとに同様のものがあったもの)の削除など。

Jakarta Security 3.0

  • 追加の認証メカニズム: ベンダーやカスタムの認証スキーマを完全に置き換えることができるようにJakarta Securityの認証メカニズムがに次のメカニズムが追加される予定です。 : Client-cert、 Digest、 OpenID Connect、 OAuth 2
  • CDIとセキュリティ:セキュリティ仕様からビルドインのBeanにインターセプターバインディングアノテーションを適用する機能を追加します。詳細はこちら。
  • FeaturesAuthorization モジュール:。ファクトリー、設定、ポリシーを含むJACCプロバイダー全体をバンドルする必要をなくしてカスタム認可ルールを簡素化。詳細はこちら。
  • 認証機構の拡張:URLごとの認証機構を含むユーザーによる認証機構の選択(プロバイダXでログイン、プロバイダYでログインなど)、複数の認証機構(JWTを試してBASIC認証に戻すなど)。

JSON Processing 2.1

  • 実装とAPIの個別のリポジトリ:仕様を以前よりベンダーに依存しないように分離しています。
  • JsonNumber の改善:一般的な数値型を使用して数値を内部に格納できるようになります。

JSON Binding 3.0

WildFlyJakarta EE 10 サポート

WildFlyニュースで説明されているように、Jakarta EE 10のサポートはWildFly 27で計画されています。WildFly 27は、次の仕様と互換性があります。

Payara のJakart EE 10 サポート

PayaraチームはEclipse Foundationの戦略的メンバーとして、Enterprise APIの革新におけるトッププレーヤーです。Payara Application Serverのリリース6でJakarta EE 10を使用できるようになります。公式のPayara Jakarta ページでニュースを確認してください: https://www.payara.fish/learn/get-started-with-jakarta-ee/

Jakarta EE に Core Profile というのが増えていた

いつの間にかCore Profileというのが増えていました。

Jakarta EE Core Profileは特に小規模なランタイムを対象としたJakartaEEプラットフォームのプロファイルを定義しています。 マイクロサービスや事前コンパイル(=GraalVM)に適したより小さなランタイムを対象としています。

プロジェクトページはこちら。

jakarta.ee

ここまでで、これはMicroProfileと何が違うんだ?という疑問にあたりまして、調べたところ会議体が違うだけで中の人もほぼ一緒なものであるという認識が出来ました。

MicroProfile自体はJava EE時代にJavaEEの仕様策定のプロセスが遅い事やリソースを十分に供給できていないということに危機感を感じたいくつかのベンダーとJavaコミュニティ主体で発生しました。そしてEclipse Fundationで管理されていくことになります。

しかしながら、そのあと紆余曲折があり、Java EE自体がEclipse Fundationで管理されるようになり、Jakarta EEと名前を変え、Oracle本体の呪縛から解き放たれ、会議体としては別ではあるものの、中の人はほぼ一緒であるという状態になってしまいました。

Core Profile側の参加メンバー(投票者の所属企業を参照)

MicroPrifle側の参加メンバー

両方に参加されているPayara*1の人はブログで、MicroProfileもJakarta EEの一部になってほしい旨を書いています。

MicroProfile and Jakarta EE Technical Alignment

現時点でも二つの仕様はほぼ同じもののようで、Devoxx UKにてCore ProfileのメンバーがMicroProfileを実装した製品について、Core Profileに適合するポテンシャルがありますと話されています。

Jakarta EE Core Profile - A Slimmer Jakarta EE by Ivar Grimstad - YouTube

仕様に表すと以下のような感じです。

f:id:megascus:20220413202844p:plain
Jakarta EE 10 Platform

https://mobile.twitter.com/Payara_Fish/status/1513502920939032582 より

f:id:megascus:20220413203001p:plain
MicroProfile

https://microprofile.io/projects/ より

ということで、私はてっきりCore Profileの方に統合されていくのかなー?と思っていたら、MicroProfile陣営もまだまだやる気のある人が居るらしくて、MicroProfile 6.0(Jakarta EE 10とAPI互換版)のリリースについても着々と進んでいるようです。

github.com

Core Profileだけに集約していくのか、両立していくのか不明なのですが、今後どうなっていくんでしょうかね?

*1:JavaJakarta EEの商用サーバーを開発している会社

JSP 3.1(Jakarta EE 10)の変更点まとめ

Jakarta EE 10でJSPのバージョンが3.1になりました。 Java EE 8ではJSPのバージョンは2.3で、そのあとの3.0はパッケージ名の変換のみだったので、 久しぶりの意味のある仕様変更になります。(定型文)

ということでまとめ。 ソースを読んで差分をざっくり眺めてるだけなので、間違い、抜け漏れは当然あります。あれ?と思った場所があったら教えてください。

ちなみに、3.0から正式名称がJakarta Server Pagesに変更されてます。(旧JavaServer Pages)

全般

意味のある仕様変更があるといったな?あれは嘘だ。

というのは言い過ぎではありますが、非推奨とされていたAPI、挙動の廃止が主となっており、あとはServletで触れたjsp-property-groupにErrorOnELNotFoundが増えた件に対応するもの、もしくはJavaDocの軽微な修正となります。

気になったのは、javadoc上lexical scope がsynchronization scopeに改められていましたが、spec上はlexical scopeのままなので、意図が不明です。。。

JPA 3.1(Jakarta EE 10)の変更点まとめ

Jakarta EE 10でJPAのバージョンが3.1になりました。 Java EE 8ではJPAのバージョンは2.2で、そのあとの3.0はパッケージ名の変換のみだったので、 久しぶりの意味のある仕様変更になります。(定型文)

ということでまとめ。 ソースを読んで差分をざっくり眺めてるだけなので、間違い、抜け漏れは当然あります。あれ?と思った場所があったら教えてください。 JPAリポジトリに仕様書が含まれてたので、そちらで確認しました。

ちなみに、3.0から正式名称がJakarta Persistence APIに変更されてます。(旧Java Persistence API)

全般

Servletの変更点の数ですらメジャーバージョンが上がってるのに比べて、マイナーバージョンしか上がってない程度に変更点がほぼありません。

ざっくり列挙すると以下の通りです。

CriteriaBuilderにいくつかのメソッドが追加されました。sign、floor、exp、ln、power、roundの数値演算用のメソッドです。JPQLにも同様の関数が追加されています。

DateTime APIをJPQL、Criteriaで扱えるようになりました。CriteriaBuilderにLocalDate、LocalDateTime、LocalTimeの現在日付を返すメソッドが追加されています。

CriteriaBuilderのいくつかのメソッドに注意事項が追加されました。modは整数除算のあまりであることが明記される等、いったい何があったんだと言いたくなるような・・・・・ JPQLと指定するパラメーターの順番が逆になってますとかは、にゃーん。

EntityManager、EntityManagerFactoryがAutoCloseableをimplimentsするようになりました。外部リソースにアクセスするものなので、むしろなんで今までimplimentsしてなかったんだ?というぐらいなのですが、静的解析で引っかかる可能性があるので注意が必要かもしれません。

GenerationType(PK生成を自動で行う場合に設定できる値)にUUIDが追加されました。UUIDを使用した場合にはB+treeインデックスのメンテナンスに時間がかかることが知られているので、あまり使うことはないと思います。*1

SPI用としてTransformerExceptionが追加されました。ユーザーには影響がありません。

ということで、ほぼ変更なしです。

Servlet 6.0(Jakarta EE 10)の変更点まとめ

Jakarta EE 10でServletのバージョンが6.0になりました。 Java EE 8ではServletのバージョンは4.0で、そのあとの5.0はパッケージ名の変換のみだったので、 久しぶりの意味のある仕様変更になります。

ということでまとめ。 ソースを読んで差分をざっくり眺めてるだけなので、間違い、抜け漏れは当然あります。あれ?と思った場所があったら教えてください。

github.com

全般

全般的にHTTP1.1準拠のRFCRFC 2616からRFC 7231に変更されました。

RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1

RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

それ以外も枝葉のRFCが全般的に変更されています。

また、過去のServlet APIで非推奨とされていたメソッド類、クラス類が削除されています。 以下のクラス類は削除されました。

  • HttpSessionContext
  • HttpUtils
  • SingleThreadModel

非推奨とされていたメソッドは、例えば以下のようなものです。

  • HttpSession#setValue()
  • HttpSession#getValue()

これらは属性のスコープの概念が取り入れられたときにattributeという名前でメソッドが置き換えられていて誰も使ってなかったはずなので、特に問題はないと思われます。 J2EE 1.3以前から生き残ってるシステムは知らね。

消されたであろうメソッドの一覧は以下に。

非推奨のリスト (Java Servlet 4.0)

いくつかのメソッドで例外的な操作が明文化されています。

例えば、nullが渡された時の挙動が明文化されているものがあります。一度値を渡してしまった後に元に戻すためにはどうすればいいの?みたいなのに答えてるのかもしれません。

APサーバーによっては挙動が変更されている(例外が発生する、何も起こらない等)かもしれないので、実際に使うときは必ずjavadocを確認するようにしてください。

HttpServletRequest

getRequestId()メソッドが追加されました。サーブレットコンテナ内で実装依存の一意の識別子を返します。マイクロサービスでリクエストの遷移を追いたいときに使えるのかもしれません。

getProtocolRequestId()が追加されました。HTTP1.X/2/3 OR AJPその他を識別するのに使用できます。

ServletConnection getServletConnection()メソッドが追加されました。ServletConnectionについては後述。(とはいっても有用なものではない)

Cookie

クッキー準拠のRFCRFC 2109からRFC 6265に変更されました。

クッキーにコメント、バージョンが入れられなくなったり、新しいRFCで追加された属性のアクセサーが生えたりしました。

また、自由な属性名でクッキーに値を入れられるようにsetAttribute(String name, String value)メソッドが追加されました。*1

セキュリティの都合等でクッキーには属性が追加されることが多々あり、 新しい属性を使わないといけない場合はCookieクラスを使えずに直接HttpServletResponse#setHeader(String name, String value)を呼び出さなければいけなかったことがこれで解消されそうです。

HttpServlet

doHeadメソッドの挙動が変更され、デフォルトでdoGetメソッドと同じ動作をするようになりました。

これが問題である場合はServletConfigの初期化パラメーターを操作して、jakarta.servlet.http.legacyDoHeadをtrueにする必要があります。

なお、今まではdoGetを実行しながらレスポンスボディを返さないという挙動をしていました。

jsp-property-groupにErrorOnELNotFound属性が追加。

EL式の挙動を変更します。詳しくは以下。

https://github.com/eclipse-ee4j/jsp-api/issues/40

ServletConnection

今回増えた唯一のクラスです。

javadocによると、デバッグ用途で使われることを想定しており、サーブレットコンテナから見た生の接続情報を提供してくれるそうです。

しかしながら現時点で取得できるのはあまり多くはないため、今後増えていくのかもしれません。

まとめ

ということで、駆け足ながら差分をざっとまとめてみました。 他にこういう差分があるよというのを見つけたら教えてください。

*1:たぶん今回の変更の中で一番うれしい

Jakarta EEって現状どうなってるんだっけ?と思ったら次のリリースがすぐだったので各社のJakarta EE仕様準拠状況をまとめた。

Jakarta EE 10が2022年第一四半期にリリースされます。つまりもうすぐです。 そういえば、Java EEってどうなったんだっけ?とか、Jakarta EEになってからどうなってるの?という人向けのまとめ記事です。

で、Jakarta EEって現状どうなってるんだっけ?ってまとめようとしたら、以下のページがいい感じにまとまっていたので、こちらを参照するとよい感じです。 https://openliberty.io/docs/22.0.0.2/jakarta-ee.html

重要なところだけ抜粋すると、

Jakarta EEプラットフォームの継続的な開発は、JESP(Jakarta EE Specification Process)を通じてJakarta開発者コミュニティによって進められ、プラットフォーム向けの新しい仕様プロジェクトを導入するための青写真が提供されています。Open LibertyなどのJakarta EE互換ランタイムは、仕様プロジェクトで記述された機能を実装しています。各実装はTechnology Compatibility Kit(TCK)を通じてコミュニティによって検証されます。TCKは、リファレンス実装の準拠性を確認するためのテスト群です。ある仕様プロジェクトが正式な仕様となるには、TCKのテストを満たすオープンソースのリファレンス実装を少なくとも1つ開発するプロセスを経て、承認される必要があります。

Open Libertyは、Jakarta EE 9.1のリファレンス実装であり、Jakarta EE Platform Specificationで定義されたJakarta EEの必須仕様を全て実装していることにあんります。Open Liberty上で動作するアプリケーションは、サーバー構成で対応するOpen Libertyの機能を有効にすることで、Jakarta EE APIを利用することができる。次の表は、最もよく使われる Jakarta EE 仕様をいくつか説明し、それに対応する Open Liberty 機能をリストアップしたものです。Try it outの欄には、Open Libertyがその仕様をどのように実装しているかを示すOpen Libertyガイドへのリンクがあります。

ということで、RIがGlassFishじゃなくて、Open Liberty(IBMのWebSphereのコミュニティ版)になってました。まじかー。

ちなみに、Jakarta EEの直近のリリースとしては以下のような感じになります。カッコ内はリリース日です。

  • Java EE 8(2017/7) Oracle がリリースした最後のJava EE
  • Jakarta EE 8(2019/9) ブランド名の変更のみ。Java EE 8と変更なし。
  • Jakarta EE 9(2020/11) パッケージ名の変更*1 およびにいくつかの機能の追加及びに削除。Jakarta EE 8以前との互換性が問題になる。※Twitterで教えてもらってアップデートしました。*2
  • Jakarta EE 9.1(2021/7) サポートするJava SEの最低バージョンをJava SE 8からJava SE 11にアップデート
  • Jakarta EE 10 (2022年第一四半期にリリース予定) Jakarta EEに名前が変わってからの最初の機能アップデート

Jakarta EE 10がどうなるかについては以下のページを確認してください。

eclipse-ee4j.github.io

InfoQにもまとまった記事があるので、サマリーの日本語訳が必要な人はそちらを。

www.infoq.com

え?第一四半期ってまじかよっ!?って思ったら、リリースプランページに明記されていました。

eclipse-ee4j.github.io

Jakarta EE 10ではまだJava 11サポートするの?という件については以下で議論がされていました。Springとの温度差を感じますね。

github.com

各APサーバーのJakarta EE仕様への対応状況

2022年3月3日時点の最新版のJakarta EE(Java EE) 仕様への対応状況は以下の通りです。

Jakarta EE 8からJakarta EE 9への移行については互換性について考慮する必要がありますので、商用サーバーは避けているのが見えます。。 現実的にはJava EE 8から移行する利点はほぼないため、既存客を考慮すれば対応しないというのも理にかなってる選択となります。 が、今後Jakarta EE 10にはいつ対応するのか?の指標にはなる気がしますね。

Oracle WebLogic Server 14.1.1.0.0

Java EE 8 Jakarta EE 8 ドキュメント上はJava EE 8ですが、Jakarta EE 8のTCKが通った一覧に記載がありました。※Twitterで教えてもらいました。*3

Oracle WebLogic Serverの新機能 14.1.1.0.0

Jakarta EE Compatible Products | Enterprise Java Application and Web Servers | The Eclipse Foundation

Eclipse GlassFish 6.2.5

Jakarta EE 9.1

Eclipse GlassFish | projects.eclipse.org

Payara Enterprise 5.36.0

Jakarta EE 8

Release notes - Payara Platform Enterprise 5.36.0 :: Payara Enterprise Documentation

WebSphere Application Server traditional 9.0.5

Java EE 7

WebSphere Application Server traditional の新機能

WebSphere Application Server Liberty 22.0.0.2

Jakarta EE 9.1Jakarta EE 8 ※コメント欄で教えてもらいました。

Jakarta EE and Java EE 8 in Liberty

Open Liberty 22.0.0.2

Jakarta EE 9.1 (リファレンス実装)

Jakarta EE overview :: Open Liberty Docs

JBoss Enterprise Application Platform 7.4

Jakarta EE 8 ※Java EE 8はサポートしない感じの表を書いてるけど別ページでは同等のものですと書いている。

JBoss Enterprise Application Platform Supported Standards - Red Hat Customer Portal

WildFly 26.0.0.Final

Jakarta EE 8 (and EE 9.1 Preview)

WildFly Documentation

※実際はEE 9.1 Previewではなくて、EE 9.1のTCK(互換性確認キット)が通ってるので、EE 9.1対応。

apache-tomee-9.0.0-M7

Jakarta EE 9.1

Apache TomEE

トップページにでかでかと9.1認証されました!って書いてあって清々しい。

Interstage Application Server V13

Jakarta EE 8

https://www.fujitsu.com/jp/documents/products/software/middleware/business-middleware/interstage/products/apserver/catalog/cz1200-18.pdf

Cosminexus:uCosminexus Application Server V11

Java EE 7

構成・機能:アプリケーションサーバ uCosminexus Application Server:クラウドサービスプラットフォーム Cosminexus:ソフトウェア:日立

WebOTX v10.4

Java EE 7

WebOTX Manual | NEC

Resion 4.0.61

Java EE 6

Resin : Changes : Resin 4.0.4 Release Notes

聞かなくなったなと思ってたら死んでたか・・・・

感想

以前はGlassFishがRIでしたが、現在はLibertyがRIになっていたのが驚きました。

ちょうど別で、Red HatHibernate(Jakarta EE、JPAのRI)の実装者を新規雇用しようとしているのもtwitterで流れてきてたし、IBM系(IBM/Red Hat)*4が結構やる気なのか?という印象を持ちました。

また、GlassFishJakarta EE 10に向けて着々と歩みを進めており、OracleGlassFishを捨てたとはいえ、その先のWebLogicに向けてどうするのかというところが注目されます。

Jakarta EEは長く停滞を続けてましたが、ここからまた変わるのでしょうかねぇ?