Java™ Plug-in とアプレットのアーキテクチャー
アプレット開発者ガイド > Java Plug-in とアプレットのアーキテクチャー
目次
このドキュメントでは、Java SE 6 update 10 リリースで導入された次世代の Java Plug-in が、アプレットの実行やアプレットとブラウザ間の対話をどのように制御するのかについて説明します。
アーキテクチャー
Java Runtime Environment
Java Plug-in では、アプレットはブラウザ内部の JVM では実行されません。代わりに、それらは個別のプロセス内で実行されます。同じ JVM プロセスを複数のアプレットで共有できますが、条件 (既存の JVM がアプレットの要件に合致するかや、アプレットを実行するためのリソースが十分に存在しているか) によっては別のプロセス内にアプレットが配置される場合もあります。アプレットは、特定バージョンの JRE を使用するように要求したり、JVM に渡す必要のあるオプションを指定したりできます。さらに、個別の JVM 内でアプレットを実行するように要求することもできます。
ただし、ブラウザとアプレットは引き続き相互に通信できます。既存の API はプロセスソケットを使用するように再設計されているため、すべてが引き続き以前と同様に機能し、変わったのは性能が向上した点だけです。このアーキテクチャーによって、次のようないくつかの利点が提供されます。
- 異なるバージョンの JRE が必要なアプレットを同時に実行できます。
- アプレットは、ヒープサイズなどの JRE 起動パラメータを指定できます。新しいアプレットの要件が既存の JRE のサブセットである場合は既存の JRE が使用され、それ以外の場合は新しい JRE インスタンスが起動されます。
- メッセージ受け渡しのインタフェースは Java で記述され、サポートされているすべてのプラットフォームで同様に実行されるため、ブラウザ間の互換性が拡張されています。
このアーキテクチャーにより、必要な場合は常に、新しい JRE を起動できます。ただし、次の条件が満たされるかぎり、アプレットは既存の JRE で実行されます。
- そのアプレットに必要な JRE バージョンが既存の JRE に一致し、かつ
- JRE の起動パラメータがそのアプレットの要件を満たす
注:
- 2 つのアプレットのそれぞれに大量のメモリーが必要な場合は、その両方が同じ JRE で実行され、どちらかがメモリー不足になる可能性があります。ただし、この問題は、複数のアプレットを同時に実行している場合にのみ発生します。
- 特定のバージョンの JRE を、Plug-in から使用不可能な JRE としてマークするには、Java コントロールパネルでそれらの JRE を無効にします。
Java Runtime Environment バージョンの選択
すべてのプラットフォームで、新しい Java Plug-in は、使用する JRE を Java コントロールパネル (「Java」タブ、「Java アプレットのランタイム設定」の下の「表示」ボタン) のリストにあるエントリから見つけます。このリスト内の使用可能な JRE は、プラットフォームに依存した場所にある deployment.properties ファイル内にエンコードされています。Windows プラットフォームの場合、それは通常 C:\Users\[username]\AppData\LocalLow\Sun\Java\Deployment に格納されています。UNIX プラットフォームの場合、それは通常 ~/.java/deployment/deployment.properties に格納されています。
Windows プラットフォームでは、Java コントロールパネルと新しい Java Plug-in の両方が、インストール済みの JRE を自動的に検出し、それを使用可能なセットに追加します。Unix プラットフォームでは、インストール済みの JRE の自動検出はサポートされていません。Java コントロールパネルの「Java」タブの「表示」をクリックしてアクセスする「Java Runtime Environment 設定」ダイアログを使用すると、新しい Java Plug-in の既知のリストに JRE を手動で追加できます。
デフォルトでは、新しい Java Plug-in はすべてのアプレットを、このリストで指定されている最新の JRE バージョンで実行します。明示的に要求されている場合にのみ、以前の JRE バージョンでアプレットを実行します。
特定の JRE バージョン (たとえば、「1.5.0_11」などの特定の更新リリース) でアプレットを起動する要求を考慮した場合:
- 使用可能な JRE のリストが参照されます。バージョン文字列が正確に一致した場合は、その JRE バージョンが選択されます。それ以外の場合で、同じファミリ内にインストール済みの JRE が 1 つ以上存在する場合は、最新バージョンが選択されます。それ以外の場合は、マシン上の最新の使用可能な JRE が選択されます。
- 選択された JRE バージョンが、そのファミリのセキュリティーベースラインと比較されます。このセキュリティーベースラインがそのバージョンに等しいか、またはそのバージョンより新しい場合は、それ以上の入力要求は行われず、そのアプレットが起動されます。
- それ以外の場合は、そのアプレットのコードが、選択された JRE バージョンの JVM インスタンスでダウンロードされます。そのアプレットが署名付きであり、かつユーザーがそのアプレットのセキュリティーダイアログボックスを受け入れた (または、コードソースがすでに信頼されている) 場合は、それ以上の入力要求は行われず、そのアプレットが起動されます。
- それ以外の場合は、「古い」JRE バージョン上の署名されていないアプレットを処理しています。このアプレットが古い JRE リリースでの実行を要求していることを示すダイアログボックスが表示され、その実行を許可するかどうかがユーザーに尋ねられます。ユーザーが「はい」をクリックすると、そのアプレットが起動されます。ユーザーが「いいえ」をクリックすると、そのアプレットが最新の使用可能な JRE バージョンでふたたび起動されます。
特定のファミリでアプレットを起動する要求を考慮した場合、そのファミリの最新の JRE が選択され、上の (2) から始まる手順が実行されます。
特定のファミリまたはそれ以降の任意のファミリでアプレットを起動する要求を考慮した場合、最新の使用可能な JRE がそのアプレットを起動するために使用されます。
スレッドに関する考慮事項
Web ブラウザの JavaScript インタプリタエンジンはシングルスレッドです。Java Plug-in は、複数のスレッドを管理できます。Java Plug-in は、アプレットごとに個別のワークスレッドを作成します。アプレット自体は、マルチスレッドである可能性があります。JavaScript から Java への呼び出しやその逆の呼び出しを行うアプレットを設計するときは、スレッド関連の問題を念頭におくようにしてください。
次の図は、JavaScript インタプリタ、Java Plug-in、およびアプレット (つまり、Java) の間のスレッドの対話を示しています。
JavaScript インタプリタがアイドル状態の場合、Java Plug-in は、アプレットのワークスレッドごとに JavaScript から Java への呼び出しをします (JavaScript インタプリタがビジー状態でないシナリオ)。
Java から JavaScript への呼び出しが進行中のときに JavaScript から Java への呼び出しが行われた場合、後者の呼び出しは、Java から JavaScript への呼び出しを行なったのと同じスレッド上で実行されます (往復のシナリオ)。
あるスレッドが Java から JavaScript への呼び出しを行なっている場合、同じ呼び出しを行おうとしている別のスレッドは、最初のスレッドが結果を受信して完了するまでブロックされます (JavaScript インタプリタがビジー状態のシナリオ)。
特に、複数のアプレットが同時に実行されている場合のスレッド関連の問題を回避するには、Java から JavaScript への呼び出しと JavaScript から Java への呼び出しの両方を短時間に抑えるとともに、可能な場合は往復を避けます。
クラスローダーキャッシュとアプレット間の対話
通常、2 つのアプレットの codebase および archive パラメータが同じである場合、これらのアプレットは同じクラスローダーのインスタンスによってロードされます。この動作は下位互換性のために必要であり、いくつかの実際のアプリケーションによって使用されています。その結果、同じ Web ページ上の複数のアプレットが Java 言語のレベルで互いの static 変数にアクセスできるため、事実上、複数のアプレットを単一のアプリケーションを構成しているかのように記述できます。
この機能を使用すると、特定の種類のアプリケーションを便利に記述できるようになりますが、一定の欠点もあります。特に、同じアプレットの複数のインスタンスがアクティブの場合は、アプレットの終了が干渉を受けます。また、アプレットの static フィールドをいつ再初期化するかや、同じアプレットの実行から実行までのどの時点で管理するかを正確に指定した条件下で使用されるため、アプレットのプログラミングモデルがより複雑になります。さらに、特定の要求を開始したアプレットを正確に特定できないため、Java Plug-in 内の特定のユーザーインタフェースの動作が不正確になる原因にもなります。
このため、新しい Java Plug-in は、アプレットごとに、アプレットでのクラスローダーキャッシュの使用から抜け出るための方法を提供します。
アプレットのガベージコレクション
destroy メソッドが終了するとただちに、アプレットインスタンスに対するガベージコレクションが実行されます。ガベージコレクションは、static 変数を除く、アプレットによって取得されたすべてのメモリーに適用されます。static 変数は、クラスローダーが存在するかぎり、クラス自体とともにクラスローダーキャッシュ内に保持されます。
では、クラスローダーはいつ消滅するのでしょうか。その動作は指定されていません。Java 仮想マシンの実装や、そのオペレーティングシステムとの対話に任されています。可能なかぎり保持されるが、メモリーがほかの目的に必要になると破棄されることが予測されます。
アプレットの特権
すべてのアプレットが、認識されている認証局からの証明書で署名されているようにしてください。ユーザーはアプレットの実行に同意する必要があり、有効な証明書があることは、そのアプレットを実行しても安全であるという、ある程度の保証をユーザーに与えます。アプレットは、承認されていないかぎり、ユーザーのシステムとの対話ができないセキュアなサンドボックス内で実行されます。その承認を得るためには、アプレットは起動時にアクセス権をリクエストする必要があり、ユーザーはそのアプレットの実行に同意する必要があります。アクセス権は、次のために必要です。
- 印刷
- ファイルシステムへのアクセス
- ブラウザの cookie へのアクセス
- その他のシステムリソースへのアクセス
基本的なアプレットセキュリティーモデルは、「全部かゼロか」の提案です。アクセス権のあるアプレットは、ユーザーのシステムにフルアクセスできます。アクセス権がない場合、アプレットは実質上まったくアクセスできません。
JNLP を使用してアプレットを配備した場合は、アプレットを、ユーザーの制御の下でユーザーのシステムに管理された状態でアクセスできる (Java Web Start アプリケーションに似た) よりきめ細かいセキュリティーモデルに利用できます。(たとえば、ユーザーによって選択されたファイルを保存したり、開いたり、印刷したりする機能。)
プロキシ構成
詳細は、『Java 配備ガイド』の「プロキシ構成」を参照してください。
セキュリティー
詳細は、『Java 配備ガイド』の「セキュリティ」を参照してください。