1. 序章

Java EEについて聞いたことがありますか？ Java 2EE、J2EE、または現在のJakarta EEはどうですか？ 実際、これらはすべて同じものの異なる名前です。JavaSEを拡張する一連のエンタープライズ仕様です。

この短い記事では、JavaEEの進化について説明します。

2. 歴史

Javaの最初のバージョンでは、Javaエンタープライズ拡張機能は単にコアJDKの一部でした。

その後、1999年のJava 2の一部として、これらの拡張機能が標準のバイナリから切り離され、J2EEまたはJava2 Platform EnterpriseEditionが誕生しました。 2006年までその名前を維持します。

2006年のJava5では、J2EEはJavaEEまたはJavaPlatformEnterpriseEditionに名前が変更されました。 その名前は、2017年9月の何か大きなことが起こったときまでずっと続いていました。

2017年9月、OracleはJavaEEの権利をEclipseFoundationに譲渡することを決定しました（言語は引き続きOracleが所有しています）。

3. 移行期に

実際、EclipseFoundationは合法的にJavaEEの名前を変更する必要がありました。 これは、Oracleが「Java」ブランドに対する権利を持っているためです。

したがって、新しい名前を選択するために、コミュニティは投票して選択しました。 ジャカルタEE。 ある意味では、それはまだです J EE。

 

*新しい名前が発表されました

しかし、これはまだ進化している話であり、ほこりは完全には落ち着いていません。

たとえば、Oracleはソースコードをオープンソース化しましたが、すべてのドキュメントをオープンソース化したわけではありませんでした。たとえば、JMSやEJBに関連しています。

新しいEclipseFoundationのドキュメントが元のドキュメントを参照できるかどうかはまだ明らかではありません。

また、不思議なことに、EclipseFoundationはjava x 名前空間を使用して新しいJavaパッケージを作成できませんが、既存のクラスとサブクラスの下に新しいクラスとサブクラスを作成できます。

この移行は、仕様を追加するための新しいプロセスをJakartaEEに追加することも意味します。 それをよりよく理解するために、 Oracleでのそのプロセスの様子と、EclipseFoundationでのプロセスの変化を見てみましょう。

4. 未来

歴史的に、機能を「EE」にするためには、次の3つが必要でした。 仕様、リファレンス実装、およびテスト。 これらの3つのことは、コミュニティの誰もが提供でき、実行委員会は、これらが言語に追加する準備ができた時期を決定します。

過去のプロセスをよりよく理解するために、 JSR、Glassfish、およびTCKとは何か、およびそれらが新しいEE機能をどのように具体化したかを詳しく見てみましょう。

また、将来何が期待できるかを垣間見ることができます。

4.1. JCPと今、EFSP

以前は、新しいEE機能が生まれたプロセスはJava Community Process（ JCP ）と呼ばれていました。

Java SEは、現在でもJCPを使用しています。 ただし、EEの所有権がOracleからEclipse Foundationに変更されたため、そのための新しい別個のプロセスがあります。 これはEclipseFoundation仕様プロセス（ EFSP ）であり、Eclipse開発プロセスの拡張です。

いくつかの重要な違いがありますが、主に「透明性、開放性、共有負担、ベンダーの中立性」に関するものです。 たとえば、EFSPの主催者は、ベンダーに中立な共同作業グループ、セルフサービスの認証プロセス、および実力主義として運営および統治する組織を想定しています。

4.2. JSR

JCPでは、EEに機能を追加するための最初のステップは、JSRまたはJavaSpecificationRequestを作成することでした。 JSRはEE機能のインターフェースに少し似ていました。JCP実行委員会は完成したJSRをレビューして承認し、JSRの貢献者はそれをコード化してコミュニティで利用できるようにしました。

この良い例は、 JSR-339 –または JAX-RS –で、最初は2011年に提案され、2012年にJCPによって承認され、最終的に2013年にリリースされました。

そして、仕様が議論されている間、コミュニティは常に参加することができましたが、時間は、 JSR 310 、 java.time、、の場合のように、実装優先のアプローチを示しました。 X204X] Joda Time –より広く受け入れられている機能とAPIを作成する傾向がありました。

したがって、EFSPは、このコードファーストの見解をその目標に反映しています。「EFSPは、仕様に文書化する価値があることを証明する方法として、最初に実践的な実験とコーディングに基づいています。」

4.3. Glassfish

次に、JCPの一部として、JSRはリファレンス実装を必要としていました。 これは、インターフェイスを実装するクラスに少し似ています。リファレンス実装は、互換性のあるライブラリの開発者や、仕様の独自の実装を作成したい他の組織に役立ちます。

Java EE機能の場合、JCPはリファレンス実装にGlassfishを使用しました。

Glassfishでのこの集中化により、実装者の検出プロセスが簡素化されましたが、その集中化にはより多くのガバナンスが必要であり、あるベンダーを別のベンダーよりも優先する傾向がありました。

したがって、EFSPはリファレンス実装を必要とせず、代わりに互換の実装のみを必要とします。 簡単に言えば、この微妙な変更により、Glassfishのような中央アーキテクチャ内の実装が、財団によって不注意に好まれないようになります。

4.4. TCK

最後に、JCPでは、EE機能をテクノロジー互換性キットまたはTCKでテストする必要がありました。

TCKは、特定のEEJSRを検証するための一連のテストでした。 簡単に言えば、 Java EEに準拠するには、アプリケーションサーバーはすべてのJSRを実装し、指定されたTCKですべてのテストに合格する必要があります。

ここではあまり変更はありません。 オラクルは、TCKとEEJSRをオープンソース化しました。 もちろん、将来のすべてのドキュメントとTCKはオープンソースになります。

5. 結論

Java EEは、確かにそれらの年の間に大きく進化しました。 それが変化し、改善し続けるのを見るのは素晴らしいことです。

今後は多くの課題がありますので、スムーズな移行を期待しましょう。