|
|
JavaTM プラグインとアプレットのアーキテクチャー
|
アプレット開発者ガイド > Java Plug-in とアプレットのアーキテクチャー
目次
このドキュメントでは、ほかのアプレットや Web ブラウザとの対話を含む、アプレット実行のさまざまな側面について説明します。
JavaSE 6u10 に実装されている次世代のプラグインでは、JRE が、ブラウザの内部では実行されなくなりました。代わりに、JRE は個別のプロセスで実行されます。デフォルトでは、すべてのアプレットが同じ JRE インスタンスで実行されます。ただし、アプレットは現在、実行に必要な JRE バージョンを指定できます。異なるバージョンの JRE が必要な場合や、アプレットに、現在ある任意のインスタンスが提供できるより多くのリソースが必要な場合は、複数の JRE インスタンスが起動されます。
ただし、ブラウザとアプレットは引き続き相互に通信できます。既存の API はプロセスソケットを使用するように再設計されているため、すべてが引き続き以前と同様に機能し、変わったのは性能が向上した点だけです。このアーキテクチャーによって、次のようないくつかの利点が提供されます。
このアーキテクチャーにより、必要な場合は常に、新しい JRE を起動できます。ただし、次の条件が満たされるかぎり、アプレットは既存の JRE で実行されます。
注:
すべてのプラットフォームで、新しいプラグインは、使用する JRE を Java コントロールパネル (「Java」タブ、「Java アプレットのランタイム設定」の下の「表示」ボタン) のリストにあるエントリから見つけます。このリスト内の使用可能な JRE は、プラットフォームに依存した場所にある deployment.properties ファイル内に符号化されています。Windows プラットフォームでは、一般に C:\Documents and Settings\[ユーザー名]\Application Data\Sun\Java\Deployment にあります。Unix プラットフォームでは、一般に ~/.java/deployment/deployment.properties にあります。
Windows プラットフォームでは、Java コントロールパネルと新しい Java Plug-in の両方が、インストール済みの JRE を自動的に検出し、それを使用可能なセットに追加します。Unix プラットフォームでは、インストール済みの JRE の自動検出はサポートされていません。Java コントロールパネルの「Java アプレットのランタイム設定」ダイアログを使用すると、新しい Java Plug-in の既知のリストに JRE を手動で追加できます。
デフォルトでは、新しい Java Plug-in はすべてのアプレットを、このリストで指定されている最新の JRE バージョンで実行します。明示的に要求されている場合にのみ、以前の JRE バージョンでアプレットを実行します。
特定の JRE バージョン (たとえば、「1.5.0_11」などの特定の更新リリース) でアプレットを起動する要求を考慮した場合:
特定のファミリでアプレットを起動する要求を考慮した場合、そのファミリの最新の 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 内の特定のユーザーインタフェースの動作が不正確になる原因にもなります。
このため、新しいプラグインは、アプレットごとに、アプレットでのクラスローダーキャッシュの使用から抜け出るための方法を提供します。
destroy メソッドが終了するとただちに、アプレットインスタンスに対するガベージコレクションが実行されます。ガベージコレクションは、static 変数を除く、アプレットによって取得されたすべてのメモリーに適用されます。static 変数は、クラスローダーが存在するかぎり、クラス自体とともにクラスローダーキャッシュ内に保持されます。
では、クラスローダーはいつ消滅するのでしょうか。その動作は指定されていません。Java 仮想マシンの実装や、そのオペレーティングシステムとの対話に任されています。可能なかぎり保持されるが、メモリーがほかの目的に必要になると破棄されることが予測されます。
アプレットは、承認されていないかぎり、ユーザーやシステムとの対話ができない安全なサンドボックス内で実行されます。この承認を取得するために、アプレットは、ユーザーが受け入れる必要のあるセキュリティー証明書を提供できます。セキュリティー証明書は、次の操作に必要です。
基本的なアプレットセキュリティーモデルは、「全部かゼロか」の提案です。セキュリティー証明書を取得した場合は、アプレットにユーザーのシステムへの完全なアクセス権を許可できます。セキュリティー証明書がない場合、アプレットには実質上アクセス権がまったくありません。
JNLP を使用してアプレットを配備した場合は、アプレットを、ユーザーの制御の下でユーザーのシステムに管理された状態でアクセスできる (Java Web Start アプリケーションに似た) よりきめ細かいセキュリティーモデルに利用できます (たとえば、ユーザーによって選択されたファイルを保存したり、開いたり、印刷したりする機能)。
関連情報
詳細は、『Java 配備ガイド』の「cookie サポート」を参照してください。
詳細は、『Java 配備ガイド』の「プロキシ構成」を参照してください。
詳細は、『Java 配備ガイド』の「セキュリティー」を参照してください。
| Copyright © 2008 Sun Microsystems, Inc. All Rights Reserved. フィードバック |
|
