Java EEは本当に何なのでしょうか。[閉まっている]

Java EEは、若いJava開発者のためにこの「神秘的な覆い」を取り囲んでいます。これは、しばらくの間自分自身を持ち上げようとしており、ほとんど成功していません。

混乱は以下から生じます：

• Java EEは、ライブラリとプラットフォームの両方のようです。通常、OracleのJava EE SDKダウンロードなどからJava EEライブラリを「取得」するには、いくつかの方法があります。ただし、コードがJava EEアプリケーションサーバー（JBoss、GlassFish、Tomcatなど）で実行されているか、Java EEアプリケーションサーバーにアクセスできる場合を除き、Java EEライブラリは機能せず、コンパイルもできません。どうして？ライブラリはアプリケーションサーバー環境外では機能しませんか？単純なコードをコンパイルしてメールを送信するためだけに、JBossのように巨大なものが必要なのはなぜですか？

• Java EEライブラリが「標準」ではなく、通常のJVMダウンロードやSDKに含まれているのはなぜですか？

• 標準Javaの主なフレーバーが2つしかないのに（Oracle JVM / SDK | OpenJDK JVM / JDK）、Java EE製品が非常に多いのはなぜですか？

• 標準のJavaではできないJava EEでできることは何ですか？

• Java EEではできない標準Javaでできることは何ですか？

• 開発者はいつJava EEが「必要」であると判断しますか？

• 開発者はいつJava EEが必要ないと判断しますか？

• Java EEライブラリのバージョンが標準のJavaライブラリリリースと同期していないのはなぜですか（Java EE 6とJava 7）。

カエルを片付けてくれてありがとう！

ライブラリがアプリケーションサーバー環境外で機能できないのはなぜですか？

実際にできます。ライブラリのほとんどは、スタンドアロンで直接使用するか（Java SEで）、. warに含めることができます（実際には、ほとんど常にTomcatです）。JPAのようなJava EEの一部には、それぞれの仕様に、Java SEでの動作と使用方法を明示する明示的なセクションがあります。

どちらかと言えば、ここで問題となっているのはアプリケーションサーバー環境自体ではなく、他のすべてのライブラリとそれらを統合する統合コードの存在です。

そのため、アノテーションは、すべてのライブラリ（EJB、JPAなど）がこのスキャンを何度も繰り返すのではなく、すべてのクラスに対して1回だけスキャンされます。また、そのため、CDIアノテーションをEJB Beanに適用し、JPAエンティティマネージャーをそれらに挿入できます。

単純なコードをコンパイルしてメールを送信するためだけに、JBossのように巨大なものが必要なのはなぜですか？

この質問にはいくつか問題があります：

1. コンパイルには、API jarのみが必要です。これは、Webプロファイルの場合は1 MB未満、完全プロファイルの場合は1 MB強です。
2. 実行するには明らかに実装が必要ですが、「大規模」は過大評価です。たとえば、OpenJDKは約75MBで、TomEE（メールサポートを含むWebプロファイルの実装）はわずか25MBです。GlassFish（フルプロファイル実装）でさえ、わずか53MBです。
3. メールは、Java SE（およびTomcat）から完全に正常に動作し、スタンドアロンのmail.jarおよびactivation.jarを使用します。

Java EEライブラリが「標準」ではなく、通常のJVMダウンロードやSDKに含まれているのはなぜですか？

ある意味でJava EEは、すでに大規模なJDKを、管理とダウンロードが容易なチャンクに分割する最初の試みの1つでした。ヘッドレスサーバーでいくつかのコマンドを実行するだけで、グラフィカルクラス（AWT、Swing）とアプレットがJREの内部にあることに人々はすでに不満を抱いています。そして、すべてのJava EEライブラリを標準のJDKに含めたいですか？

モジュール性のサポートが最終的にリリースされると、多くのものがパッケージとして個別にインストールできる小さな基本JREができます。たぶん、Java EEを構成する多くのクラス、あるいはすべてのクラスも、おそらくそのようなパッケージになるでしょう。時が教えてくれる。

標準Javaの主なフレーバーが2つしかないのに（Oracle JVM / SDK | OpenJDK JVM / JDK）、Java EE製品が非常に多いのはなぜですか？

Java SEには、2つ以上のフレーバーがあります。少なくともIBM JDK、以前のBEAのもの（買収のためにOracle / Sunのものに統合されているJRocket）、他のさまざまなオープンソース実装、および組み込みで使用するための多数の実装があります。

Java SEおよびEEが仕様であることの背後にある理由は、多くのベンダーおよび組織がそれを実装できるため、競争を促進し、ベンダーロックインのリスクを軽減するためです。

これは、CおよびC ++コンパイラでも同じです。競合する多くの製品があり、すべてC ++標準に準拠しています。

Java EEライブラリのバージョンが標準のJavaライブラリリリースと同期していないのはなぜですか（Java EE 6とJava 7）

Java EEはJava SEをベースに構築されているため、遅れをとっています。ただし、バージョンは対応しています。Java EE 5にはJava SE 5が必要です。JavaEE 6にはJava SE 6などが必要です。それは主に、Java SE Xが最新であるとき、Java EE X-1が最新であるということだけです。

ここにあなたの質問に対するいくつかの素早く構成された答えがあります...

• アプリケーションサーバーなしでJavaEEライブラリが機能しないのはなぜですか？ JavaEEが提供するサービス（コンテナ管理のトランザクション、コンテナ管理の依存性注入、タイマーサービスなど）には、本質的にJavaEE準拠のアプリケーションサーバー（GlassFish、JBoss、WebSphereなど）が含まれます。したがって、JavaEEライブラリはそのようなコンテナなしでは何の役にも立ちません。「メールを送信するための単純なコードをコンパイルするためだけに、JBossと同じくらい巨大なものが必要なのはなぜですか？」必要ありません。JavaEEを使用せずにメールを送信する方法はいくつかありますが、JavaEEの方法で送信する場合は、JavaEEコンテナが必要です。

• JavaEEライブラリにJavaSEダウンロードが含まれていないのはなぜですか？ 多くのライブラリが含まれていないのと同じ理由：それはやり過ぎです。アプリケーションサーバーなしではJavaEEライブラリを使用することさえできないので、なぜそれらを含めるのが面倒なのでしょうか。開発者がアプリケーションサーバーをインストールしてJavaEEを使用する場合は、JavaEEをダウンロードする必要があります。

• なぜそんなに多くのJavaEEオファリングがあるのですか？ 本当に「とても」多くの JavaEEオファリングはありますか？もしそうなら、それらのいくつかを挙げてください。より正確には、同じAPIの複数の実装があると思います。

• JavaEEを使用して、標準のJavaがなければ実行できないことは何ですか？ たくさん。JavaEEなしでは、アプリケーションサーバーに依存してトランザクションや永続化コンテキストを管理することはできません。アプリケーションサーバーがJavaEEなしでEJB依存性注入を管理することを許可することはできません。JavaEEがないと、アプリケーション管理のタイマーサービスを使用できません。この質問に対する答えは、最初の質問に対する答えを非常に明確にするはずです... JavaEEによって提供されるサービスのほとんどは、JavaEEコンテナーを必要とします。

• JavaEEではできないJavaSEでできることは何ですか？ ええと…わかりません。

• 開発者はいつJavaEE が必要だと判断しますか？ この質問は完全に主観的です...しかし、JavaEEによって提供されるサービスのいずれかが必要な場合は、それについて考え始めます。JavaEEが何かわからない場合は、おそらく必要ありません。

• 開発者はいつJavaEEが必要ないと判断しますか？ 前の回答を参照してください。

• JavaEEライブラリのバージョンがJavaSEのバージョンと同期しないのはなぜですか？ 良い質問。私はそれに答える方法を知っているふりをしません...しかし、答えは「彼らが同期していないから」だと思います。

Java EEは鳥瞰的に見ると、プラットフォーム、つまり私たちが構築できるものです。

より技術的な観点から、Java Enterprise Edition標準は、エンタープライズアプリケーションの構築に一般的に使用される一連のAPIを定義しています。これらのAPIはアプリケーションサーバーによって実装されます。もちろん、異なるアプリケーションサーバーは、Java EE APIの異なる実装を自由に使用できます。

ただし、コードがJava EEアプリケーションサーバー（JBoss、GlassFish、Tomcatなど）で実行されているか、Java EEアプリケーションサーバーにアクセスできる場合を除き、java eeライブラリは機能せず、コンパイルもできません。

Java EE APIに対してコンパイルするため、これらのAPIはコンパイル時にのみ必要です。実行時には、これらのAPIの実装、つまりアプリケーションサーバーも必要です。

単純なコードをコンパイルしてメールを送信するためだけに、JBossのように巨大なものが必要なのはなぜですか？

あなたはしません。ただし、メールの送信にJava EE APIを使用する場合は、実行時にそのAPIを実装する必要があります。これは、アプリケーションサーバーによって提供されるか、クラスパスに追加するスタンドアロンライブラリによって提供されます。

Java EEライブラリが「標準」ではなく、通常のJVMダウンロードやSDKに含まれているのはなぜですか？

APIのみが標準化されているため、実装は標準化されていません。

なぜそれほど多くのJava EE製品があるのですか

特定の機能を実装するための正しい方法について人々が同意しないためです。さまざまなベンダーが市場シェアをめぐって争うからです。

標準のJavaではできないJava EEでできることは何ですか？

Java EE実装は「標準Java」で構築されているため、何もありません。ただし、一般的な企業の問題を​​解決する場合は、既存のライブラリを利用すると多大な労力を節約でき、標準化されたAPIを使用するとベンダーのロックインを防ぐことができます。

Java EEではできない標準Javaでできることは何ですか？

Java EEにはJava SEが含まれているため、何もありません。

開発者はいつJava EEが「必要」であると判断しますか？開発者はいつJava EEが必要ないと判断しますか？

一般的に言って、Java EE APIは、エンタープライズコンピューティングにおける典型的な繰り返し発生する問題を解決します。そのような問題がある場合、通常は標準のソリューションを使用するのが理にかなっていますが、別の問題がある場合は、別のソリューションが必要になることがあります。たとえば、リレーショナルデータベースと通信する必要がある場合は、JPAの使用を検討する必要があります。しかし、リレーショナルデータベースが必要ない場合、JPAは役立ちません。

Java EEとは何ですか？

ウィキでの正規性の定義から始めましょう：

Java Platform、Enterprise EditionまたはJava EEは、OracleのエンタープライズJavaコンピューティングプラットフォームです。このプラットフォームは、ネットワークおよびWebサービスを含むエンタープライズソフトウェア、およびその他の大規模、多層、スケーラブル、信頼性の高い、安全なネットワークアプリケーションを開発および実行するためのAPIおよびランタイム環境を提供します。

ここでの要点は、Java EEはAPIを提供するプラットフォームであり、具体的なライブラリではないということです。

Java EEには何が必要ですか？

Java EEの主な範囲は、ネットワークベースのアプリケーションです。これは、単純なネットワークサポートを備えたデスクトップアプリケーション開発を指向したJava SEとは異なります。これが両者の主な違いです。すべてのアプリケーションに対するスケーラビリティ、メッセージング、トランザクション、DBサポート...ネットワークの進化に伴い、これらすべてのニーズが高まっています。もちろん、Java SEが提供する既製のソリューションの多くはネットワーク開発に役立つため、Java EEはJava SEを拡張します。

コードを実行するためにアプリケーションサーバーが必要なのはなぜですか？

なぜ操作システムが必要なのですか？ハードウェアでの多くの苦痛な作業があるので、最も単純なアプリケーションを作成するためにも私たちが行う必要があるのです。そしてOSなしでは、何度もそれを行う必要があります。過度に単純化されたOSは、アプリケーションを実行するためのグローバルコンテキストを提供する単なるプログラムコンテナーです。

そして、これがアプリケーションサーバーです。それらは、私たちのアプリケーションをそのコンテキストで実行することを可能にし、企業の高負荷ネットワークアプリケーションに必要な多くの高レベルの機能を提供します。そして、この問題を解決するために独自の自転車を作成するのではなく、ビジネスニーズを満たすコードを作成したいのです。

ここでのもう1つの例は、JVM for Javaです。

Java EEにオンボードアプリケーションサーバーが含まれていないのはなぜですか？

私には言いがたい。柔軟性を高めるために行われたと思います。Java EEは何をすべきかを述べ、彼らはそれを行う方法を決定します。

JVMにJava EEが含まれていないのはなぜですか？

彼らは異なる市場セクターに向けたからです。Java EEには、通常のデスクトップに必要のない機能がたくさんあります。

なぜそれほど多くのJava EE製品があるのですか？

Java EEは動作を説明するだけだからです。誰でも実装できます。

Java EEでできることは、Java SEではできないことです。

インターネットを征服する。Java SEアプレットとソケットを使うのは本当に難しいです:)

Java EEではできないJava SEでできることは何ですか？

上記のように、Java EEはJava SEを拡張するため、Java EEを使用すると、Java SEで利用可能なすべてのことを実行できるはずです。

開発者はいつJava EEが「必要」であると判断しますか？

Java EEのパワーが必要な場合。上記のすべて。

開発者はいつJava EEが必要ないと判断しますか？

通常のコンソールまたはデスクトップアプリケーションを作成するとき。

Java SEとJava EEのバージョンが同期されないのはなぜですか？

Javaは、そのテクノロジーの命名とバージョン管理に常に問題を抱えていました。したがって、この状況は例外ではありません。

Java EEはすべてコンテナーの概念についてです。
コンテナは、アプリケーションを実行し、この最後の一連のサービスを提供する実行コンテキストです。各種類のサービスは、JSRという名前の仕様によって定義されます。たとえば、JSR 907、JTA（JavaトランザクションAPI）は、さまざまなリソースに対する分散トランザクションを管理する標準的な方法を提供します。
一般に、特定のJSRにはさまざまな実装があり、使用する実装はコンテナープロバイダーによって異なりますが、動作が事前定義されたコントラクト（JSR API）を尊重していることは確かなので、気にしないでください。
したがって、Java EEを利用するには、コンテナー内でアプリケーションを実行する必要があります。2つの主なものはEJBとサーブレットコンテナで、どちらもJava EE認定のアプリケーションサーバーに存在します。

これらすべての目的は、必須のid.estだけでアプリケーションをパッケージ化できるように、標準の実行環境を定義することです。あなたのビジネス。それ以外の場合はパッケージ化してアプリに提供しなければならない、サーバー上の他のアプリとの競合の原因となる可能性のある未知のさまざまなサードパーティライブラリセットに依存することを避けます。Java EEでは、セキュリティ、トランザクション、スケーラビリティ、リモート呼び出しなどの標準的な非機能要件がすべてコンテナによって提供されることがわかっており（コンテナ内で実行されるすべてのアプリに対して因数分解されます）、それに基づいて作業を行う必要があります。