Java EE vs J2EE vs Jakarta EE

1. 前書き

Java EEについて聞いたことがありますか? Java 2EE、J2EE、または現在のジャカルタEEはどうですか? 実際、*これらは同じもののすべての異なる名前です:Java SEを拡張するエンタープライズ仕様のセット*。
この短い記事では、Java EEの進化について説明します。

2. 歴史

Javaの最初のバージョンでは、Javaエンタープライズ拡張は単にhttp://titanium.cs.berkeley.edu/doc/java-langspec-1.0/ [コアJDKの一部]でした。
その後、1999年のJava 2の一部として、これらの拡張機能は標準のバイナリ、_J2EE_、またはhttps://www.oracle.com/technetwork/java/javaee/documentation/introduction-140137.html[Java 2 Platform Enterprise Edition]が誕生しました。 その名前は2006年まで保持されます。
2006年のJava 5では、J2EEはJava EEまたはJava Platform Enterprise Editionに名前が変更されました。 その名前は、*何か大きなことが起こった* 2017年9月までずっと続きます。
  • 2017年9月、https://blogs.oracle.com/theaquarium/opening-up-ee-update [オラクルは、Java EEの権利をEclipse Foundationに譲渡することを決定しました]を参照してください(この言語はまだOracleが所有しています)*。

3. 移行期に

実際、Eclipse Foundationは合法的にJava EEの名前を変更しました。 これは、Oracleが「Java」ブランドに対する権利を持っているためです。
新しい名前を選択するために、コミュニティは次のように投票して選択しました。* Jakarta EE。*
link:/uploads/java_evolution-1-100x82.png%20100w []
 
*新しい名前が発表されました
しかし、これはまだ進化している物語であり、塵は完全に解決していません。
*たとえば、Oracleはソースコードをオープンソース化しましたが、すべてのドキュメントをオープンソース化しませんでした*。例:JMSおよびEJB。
新しいEclipse Foundationドキュメントがオリジナルを参照できるかどうかはまだ明確ではありません。
また、不思議なことに、Eclipse Foundationは_javax_名前空間を使用して新しいJavaパッケージを作成できませんが、既存のクラスとサブクラスの下に新しいクラスとサブクラスを作成できます。
また、移行はhttps://www.eclipse.org/projects/efsp/ [仕様を追加するための新しいプロセス]をJakarta EEに意味します。 それをよりよく理解するために、* Oracleでのプロセスがどのようなもので、Eclipse Foundationでどのように変化するかを見てみましょう。*

4. 未来

歴史的に、機能を「EE」にするためには、3つのものが必要でした:**仕様、参照実装、およびテスト。 **これらの3つのものは、コミュニティの誰でも提供でき、実行委員会がこれらを言語に追加する準備ができたら決定します。
過去のプロセスをよりよく理解するために、JSR、Glassfish、およびTCKが何であるか、およびそれらがどのように新しいEE機能を具体化するかを詳しく見てみましょう*。
また、将来的に何を期待するかも一目でわかります。

4.1. JCP、そして今、EFSP

以前は、新しいEE機能が生まれたプロセスはJava Community Process(https://jcp.org/en/home/index[JCP])と呼ばれていました。
Java SEは現在もJCPを使用しています。 しかし、EEの所有権がOracleからEclipse Foundationに変更されたため、そのための新しい別個のプロセスがあります。 これはEclipse Foundation Specification Process(https://www.eclipse.org/projects/efsp/[EFSP])であり、https://www.eclipse.org/projects/dev_process[Eclipse Development Process。]の拡張版です。
https://blogs.eclipse.org/post/tanja-obradovic/how-eclipse-foundation-specification-process-efsp-different-java-community [いくつかの重要な違い]がありますが、ほとんどの場合、透明性、開放性、共有負担、ベンダー中立性。 たとえば、EFSPオーガナイザーは、ベンダーに中立な共同作業グループ、セルフサービスの認証プロセス、実力主義として運営および管理する組織を想定しています。

4.2. JSRs

JCPでは、EEに機能を追加する最初のステップは、JSRまたはJava仕様要求を作成することでした。 * JSRはEE機能の_interface_に少し似ていました。* JCP実行委員会は完成したJSRをレビューおよび承認し、JSRの貢献者がそれをコーディングしてコミュニティで利用できるようにしました。
この良い例は、https://jcp.org/en/jsr/detail?id=339[JSR-339] –またはlink:/jax-rs-spec-and-implementations [ JAX-RS]-当初2011年に提案され、2012年にJCPによって承認され、最終的に2013年にリリースされました。
そして、仕様が議論されている間、コミュニティは常に圧迫されていましたが、時間は、実装優先のアプローチ-https://jcp.org/en/jsr/detail?id=310[JSR 310]、__ https://www.baeldung.com/java-8-date-time-intro [java.time]、__and link:/joda-time[Joda Time] –傾向があるより広く受け入れられている機能とAPIを作成します。
そのため、EFSPはこのコードファーストビューをその目標に反映しています。「EFSPは、何かを仕様に文書化する価値があることを証明する方法として、最初に実践的な実験とコーディングに基づきます。」

4.3. グラスフィッシュ

次に、JCPの一部として、JSRにはリファレンス実装が必要でした。 *これは、_interface_を実装する_class_に少し似ています。*参照実装は、互換性のあるライブラリの開発者や、仕様の独自の実装を作成する他の組織を支援します。
Java EE機能の場合、JCPはその参照実装にGlassfishを使用しました。
また、Glassfishのこの集中化により実装者の発見プロセスが簡素化されましたが、その集中化にはより多くのガバナンスが必要であり、あるベンダーを別のベンダーよりも好む傾向がありました。
したがって、EFSPは参照実装を必要とせず、代わりに__compatible __implementationのみを必要とします。 簡単に言うと、この微妙な変更により、Glassfishのような中央アーキテクチャ内での実装が、財団によって不注意に優先されることはありません。*

4.4. TCK

最後に、JCPはEE機能がTechnology Compatibility Kitまたはhttps://projects.eclipse.org/projects/ee4j.jakartaee-tck[TCK]を介してテストされることを要求しました。
TCKは、特定のEE JSRを検証するための一連のテストでした。 簡単に言えば、* Java EEに準拠するには、アプリケーションサーバーはすべてのJSRを実装し、指定されたTCKですべてのテストに合格する必要があります。*
ここではあまり変更はありません。 Oracleは、TCKおよびEE JSRをオープンソース化しました。 もちろん、将来のすべてのドキュメントとTCKはオープンソースになります。

5. 結論

Java EEは、確かにこの数年間で大きく進化しました。 それが変化し改善され続けるのを見るのは素晴らしいことです。
今後は多くの課題がありますので、スムーズな移行を期待しましょう。