このトピックでは、Javaアプレットの開発およびデプロイに関する情報を提供します。Javaアプレットでは、ブラウザでの実行にJava Plug-inテクノロジを使用します。
この節の内容は以下のとおりです。
Java Runtime Environment (JRE)に含まれているJava Plug-inテクノロジ(以降、「Java Plug-in」と呼ぶ)を使用すると、Javaアプレットをデスクトップ上のWebブラウザで実行できます。Java Plug-inは、Webブラウザ内のアプレットに強力な機能を提供するとともに、下位互換性のある方法でアプレットの全体的な信頼性と機能を向上させます。
Java Plug-inでは、周囲のWebページとの完全な相互運用のためにブラウザに接続しなおす1つ以上のJava仮想マシン・インスタンス(JVM)を実行します。このアーキテクチャの変更によって多くの利点と機能がもたらされます。
アプレットを実行しているJVMは、オペレーティング・システムのレベルでWebブラウザから切り離されます。アプレットの実行中に不具合が発生したり、非協力的なアプレットがシャットダウンを拒否したりした場合は、Java Plug-inがエラー状態を検出して適切に処理するため、Webブラウザは影響を受けません。
Java Plug-inはバックグラウンドでアプレットを起動するため、Webブラウザの応答性が常に維持されます。アプレットは、実行の準備ができるとすぐにWebページに表示されます。
Java Plug-inでは、アプレットをJNLPファイルから直接起動する機能が提供されるため、ブラウザの内部とブラウザの外部(Java Web Startを使用)の両方でのJavaコンテンツの配備が統合されます。開発者は、高度機能用のJNLP拡張機能を再利用できます。アプレットは、永続データ・ストレージ、ローカル・ファイル・システムへのアクセス、およびサンドボックス化されたコードからのその他の有効な機能のためにJNLP APIにアクセスできます。
Webブラウザ内のJavaScriptエンジンとJavaプログラミング言語の橋渡しとなるのが下位互換性で、JavaアプレットからJavaScriptコードを呼び出す場合も、JavaScriptコードからJavaアプレットを呼び出す場合も、信頼性、パフォーマンス、ブラウザ間の移植性があることを特徴付けています。
コマンド行アプリケーションと同じ大きさのヒープ領域をアプレットで利用できます。
JVMコマンド行引数をWebページのHTMLでアプレットごとに指定できるため、ヒープ・サイズやJava 2Dハードウェア高速化機能などのオプションをきめ細かく制御できるようになりました。
各アプレット・インスタンスは、実行するJREバージョンを個別に要求できます。Java Plug-inでは、特定のJREバージョンまたは特定のファミリ内の任意のJREバージョンの両方の選択がサポートされています。
アプレット開発チュートリアル(アプレットの開発や配備に関する様々な側面について説明した包括的なJavaチュートリアル)を参照してください。
この項では、Java Plug-inがアプレットの実行やアプレットとブラウザ間の対話をどのように制御するのかについて説明します。
Java Plug-inでは、アプレットはブラウザ内部のJVMでは実行されません。代わりに、それらは個別のプロセス内で実行されます。同じJVMプロセスを複数のアプレットで共有できますが、条件(既存のJVMがアプレットの要件に合致するかや、アプレットを実行するためのリソースが十分に存在しているか)によっては別のプロセス内にアプレットが配置される場合もあります。アプレットは、特定バージョンのJREを使用するように要求したり、JVMに渡すオプションを指定したりできます。さらに、個別のJVM内でアプレットを実行するように要求することもできます。
ただし、ブラウザとアプレットは引き続き相互に通信できます。既存のAPIはプロセスソケットを使用するように再設計されているため、すべてが引き続き以前と同様に機能し、変わったのは性能が向上した点のみです。このアーキテクチャによって、次のようないくつかの利点が提供されます。
異なるバージョンのJREが必要なアプレットを同時に実行できます。
アプレットは、ヒープ・サイズなどのJRE起動パラメータを指定できます。(新しいアプレットの要件が既存のJREのサブセットである場合は既存のJREが使用され、それ以外の場合は新しいJREインスタンスが起動されます。)
メッセージ受渡しのインタフェースはJavaで記述され、サポートされているすべてのプラットフォームで同様に実行されるため、ブラウザ間の互換性が拡張されています。
このアーキテクチャにより、必要な場合は常に、新しいJREを起動できます。ただし、次の条件が満たされる場合は、アプレットは既存のJREで実行されます。
アプレットに必要なJREバージョンが既存のJREに一致します。
JREの起動パラメータがアプレットの要件を満たしています。
注意:
|
すべてのプラットフォームでは、Java Plug-inは、使用するJREをJavaコントロール・パネル(「Java」タブの「表示」ボタン)のリストにあるエントリから見つけます。このリスト内の使用可能なJREは、プラットフォームに依存した場所にあるdeployment.properties
ファイル内にエンコードされています。Windowsプラットフォームの場合、それは通常C:\Users\[username]\AppData\LocalLow\Sun\Java\Deployment
に格納されています。Solaris、LinuxおよびOS Xプラットフォームの場合、それは通常~/.java/deployment/deployment.properties
に格納されています。
Windowsプラットフォームでは、Javaコントロール・パネルとJava Plug-inの両方が、インストール済のJREを自動的に検出し、それを使用可能なセットに追加します。Solaris、LinuxおよびOS Xプラットフォームでは、インストール済のJREの自動検出はサポートされていません。Javaコントロール・パネルの「Java」タブの「表示」をクリックしてアクセスする「Java Runtime Environment設定」ダイアログを使用すると、Java Plug-inの既知のリストにJREを手動で追加できます。
デフォルトでは、Java Plug-inはすべてのアプレットを、このリストで指定されている最新のJREバージョンで実行します。Java Plug-inは、明示的に要求されている場合のみ、以前のJREバージョンでアプレットを実行します。
特定のJREバージョン(たとえば、「1.5.0_11」などの特定の更新リリース)でアプレットを起動する要求を考慮した場合:
使用可能なJREのリストが参照されます。バージョン文字列が正確に一致した場合は、そのJREバージョンが選択されます。それ以外の場合で、同じファミリ内にインストール済みのJREが1つ以上存在する場合は、最新バージョンが選択されます。それ以外の場合は、マシン上の最新の使用可能なJREが選択されます。
選択されたJREバージョンが、そのファミリのセキュリティ・ベースラインと比較されます。(詳細は、「Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer」を参照してください。)このセキュリティ・ベースラインがそのバージョンに等しいか、またはそのバージョンより新しい場合は、それ以上の入力要求は行われず、そのアプレットが起動されます。
それ以外の場合は、そのアプレットのコードが、選択されたJREバージョンのJVMインスタンスでダウンロードされます。そのアプレットが署名付きであり、かつユーザーがそのアプレットのセキュリティ・ダイアログ・ボックスを受け入れた(または、コード・ソースがすでに信頼されている)場合は、それ以上の入力要求は行われず、そのアプレットが起動されます。
それ以外の場合は、「古い」JREバージョン上の署名されていないアプレットを処理しています。このアプレットが古いJREリリースでの実行を要求していることを示すダイアログ・ボックスが表示され、その実行を許可するかどうかがユーザーに尋ねられます。ユーザーが「はい」をクリックすると、そのアプレットが起動されます。ユーザーが「いいえ」をクリックすると、そのアプレットが最新の使用可能なJREバージョンでふたたび起動されます。
特定のファミリでアプレットを起動する要求を考慮した場合、そのファミリの最新のJREが選択され、上の(2)から始まるステップが実行されます。
特定のファミリまたはそれ以降の任意のファミリでアプレットを起動する要求を考慮した場合、最新の使用可能なJREがそのアプレットを起動するために使用されます。
WebブラウザのJavaScriptインタプリタ・エンジンはシングル・スレッドです。Java Plug-inは、複数のスレッドを管理できます。Java Plug-inは、アプレットごとに個別のワーカー・スレッドを作成します。アプレット自体は、マルチスレッドである可能性があります。JavaScriptからJavaへの呼出しやその逆の呼出しを行うアプレットを設計するときは、スレッド関連の問題を念頭におくようにしてください。
次の図は、JavaScriptインタプリタ、Java Plug-in、およびアプレットの間のスレッドの対話を示しています。
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は、アプレットごとに、アプレットでの12.3.5項「クラス・ローダー・キャッシュ」の使用から抜け出るための方法を提供します。
destroy
メソッドが終了するとただちに、アプレット・インスタンスに対するガベージ・コレクションが実行されます。ガベージ・コレクションは、static変数を除く、アプレットによって取得されたすべてのメモリーに適用されます。static変数は、クラス・ローダーが存在するかぎり、クラス自体とともにクラス・ローダー・キャッシュ内に保持されます。
では、クラス・ローダーはいつ消滅するのでしょうか。その動作は指定されていません。Java仮想マシンの実装や、そのオペレーティング・システムとの対話に任されています。可能なかぎり保持されるが、メモリーがほかの目的に必要になると破棄されることが予測されます。
ユーザー操作性を向上させるために、すべてのアプレットに、認識されている認証局からの有効な証明書で署名します。アプレットは、承認されていないかぎり、ユーザーのシステムとの対話ができないセキュアなサンドボックス内で実行されます。その承認を得るためには、アプレットは起動時にアクセス権を要求する必要があり、ユーザーはそのアプレットの実行に同意する必要があります。アクセス権は、次のために必要です。
印刷
ファイル・システムへのアクセス
ブラウザのcookieへのアクセス
その他のシステム・リソースへのアクセス
基本的なアプレット・セキュリティ・モデルは、「全部かゼロか」の提案です。アクセス権のあるアプレットは、ユーザーのシステムにフル・アクセスできます。アクセス権がない場合、アプレットは実質上まったくアクセスできません。
JNLPを使用したアプレットのデプロイメントによって、アプレットはJava Web Startアプリケーションに似たJNLP APIにアクセスでき、これはアプレットがユーザーの制御の下で管理された状態でユーザーのシステムにアクセスできます。たとえば、JNLPを使用すると、ユーザーによって選択されたファイルを保存したり、開いたり、印刷したりできます。
アプレットは、applet
、object
またはembed
タグを、必要なパラメータとともに手動でコーディングすることによってデプロイできます。このセクションでは、これらのパラメータについて説明します。ただし、ブラウザ間の互換性を保証するために、配備ツールキットを使用してアプレットをデプロイすることをお薦めします。配備ツールキットの使用の詳細は、第19章「ブラウザでのデプロイメント」を参照してください。
Java Plug-inでは、アプレットがロードされる前に表示されるイメージのカスタマイズ機能が向上しています。動画GIFは、image
パラメータのターゲットとしてサポートされています。また、次のパラメータもサポートされています。
アプレットがロードされる前に表示されるイメージの表示中に、アプレット領域の縁の周囲に1ピクセル幅の境界を描画するべきかどうかを示すboolean型パラメータ。デフォルトはtrue
です。ちらつきの発生を防止するために、特にロード・イメージとして動画GIFを使用している場合は、この値をfalse
に設定することをお薦めします。
ロード・イメージを左上隅から表示し始めるのではなく、アプレット領域内の中央にそろえるべきかどうかを示すboolean型パラメータ。デフォルトはfalse
です。
boxborder
パラメータとcenterimage
パラメータの使用例を次に示します。
<APPLET archive="large_archive.jar" code="MyApplet" width="300" height="300"> <!-- Use an animated GIF as an indeterminate progress bar while the applet is loading --> <PARAM NAME="image" VALUE="animated_gif.gif"> <!-- Turn off the box border for better blending with the surrounding web page --> <PARAM NAME="boxborder" VALUE="false"> <!-- Center the image in the applet's area --> <PARAM NAME="centerimage" VALUE="true"> </APPLET>
Java起動時にアプリケーションがJNLPクライアントに使用させる標準の仮想マシンの引数と非標準の仮想マシンの引数の追加セットを指定します。java_arguments
とjava-vm-args
の両方が存在する場合は、java-vm-args
引数が優先されます。
このアプレット・インスタンスの実行時に使用されるJVMコマンド行引数を指定します。ほぼすべてのJVMコマンド行引数がサポートされていますが、特定の規則や制限が存在します。java_arguments
とjava-vm-args
の両方が存在する場合は、java-vm-args
引数が優先されます。
java_arguments
オプションは、アプレットの起動中にクライアントのJava VMが再起動されないようにすることを主な目的としています。良い方法として、java_arguments
とjava-vm-args
の両方を指定する場合は、それらに同じ値を含めるようにしてください。
特定のアプレットを独自のJVMインスタンス内で実行すべきであることを指定するboolean型パラメータ。このパラメータは、同じJVM内で実行され、ヒープ・スペースやその他のリソースを消費している可能性のあるほかのアプレットからのどのような干渉も許容できない、特定の強力なデスクトップ・アプレットをサポートします。
<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300"> <PARAM name="java_arguments" value="..."> <PARAM name="separate_jvm" value="true"> </APPLET>
シナリオ1: 両方のパラメータが定義され、それらの値が異なっています。
java_arguments = -Xmx256m java-vm-args = -verbose
すべてのプラットフォーム上で必要な動作: -verbose
JVMは最初に、java_arguments
タグで指定された値を使用して起動します。クライアントJVMは不一致を検出し、-verbose
のみを使って再起動します。警告がJavaコンソールに出力されます。
シナリオ2: 両方のパラメータが定義され、java-vm-args
で指定された値が、java_arguments
で指定された値のサブセットになっています。
java_argument = -Xmx256m -verbose java-vm-args = -verbose
すべてのプラットフォーム上で必要な動作: -verbose
JVMは最初に、java_arguments
で指定された完全な引数セットを使用して起動します。クライアントJVMは不一致を検出し、java-vm-args
で指定された小さい引数セットのみを使って再起動します。パラメータの不一致に関する警告がJavaコンソールに出力されます。
シナリオ3: java_arguments
タグはHTMLファイルで定義されているが、java-vm-args
タグはJNLPファイルで定義されていません。
java_arguments = -Xmx256m java-vm-args = [not defined]
すべてのプラットフォーム上で必要な動作: [no jvm params]
JVMは最初に、java_arguments
で指定された値を使用して起動します。クライアントJVMは不一致を検出し、パラメータを使わずにJVMを再起動します。パラメータの不一致に関する警告がJavaコンソールに出力されます。
シナリオ4: java_arguments
タグはHTMLファイルで定義されていないが、java-vm-args
タグはJNLPファイルで定義されています。
java_arguments = [not defined] java-vm-args = -Xmx256m
すべてのプラットフォーム上で必要な動作: -Xmx256m
java_arguments
タグには何も指定されていないため、JVMは最初にJVM引数を使用せずに起動します。クライアントJVMは不一致を検出し、java-vm-args
で指定された値を使ってJVMを再起動します。
デフォルトより大きい最大ヒープ・サイズの指定:
<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300"> <PARAM name="java_arguments" value="-Xmx128m"> </APPLET>
デフォルト以外のヒープ・サイズと、Java Binding for the OpenGL API (JOGL)を介してOpenGLを使用するアプレットで通常使われるJava 2Dハードウェア・アクセラレーション・オプションの指定:
<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300"> <PARAM name="java_arguments" value="-Xmx256m -Dsun.java2d.noddraw=true"> </APPLET>
ガベージ・コレクタの冗長出力と、Javaプログラミング言語でのアサーション機能の有効化:
<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300"> <PARAM name="java_arguments" value="-verbose:gc -ea:MyApplet"> </APPLET>
「Java Web Start開発者ガイド」の「JNLPファイルの構文」のセクションには、一連の「安全な」JVMコマンド行引数およびシステム・プロパティが定義されています。Java Plug-inでは、java_arguments
パラメータで指定されたすべてのJVMコマンド行引数がセキュアであるかぎり、アプレットや、それによってロードされるどのクラスもアクセス権なしで実行できます。
java_arguments
パラメータでは、安全でないJVMコマンド行引数(つまり、安全なリストに記載されていないコマンド行引数)が指定される可能性もあります。この場合は、セキュリティ上の問題が発生する可能性があるため、Java Plug-inによって、署名されていないクラスをロードできないという規則が適用されます。つまり、このようなJVMインスタンスでは、ユーザーがセキュリティ・ダイアログ・ボックスを受け入れた信頼されたコードのみをロードできます。セキュリティ保護されていないシステム・プロパティが指定されたJVMインスタンスで、署名なしの、または信頼されていないクラスをロードしようとした場合は、署名がないために指定されたクラスをロードできなかったことを示すClassNotFoundException
がスローされます。
java_arguments
パラメータで渡すことのできるコマンド行引数に関する制限はごく少数しかありません。一般に、-Xbootclasspath
引数のほか、-classpath
や-jar
などの、パスを指定するために使用されるコマンド行引数はすべて禁止されます。ほかの(現在および将来の)コマンド行引数はすべて、上記の安全なコマンド行引数と安全でないコマンド行引数についての注意書きを付けてサポートするようにしてください。
java_arguments
パラメータで渡されたコマンド行引数は、Javaコントロール・パネルの「Java Runtime Environment設定」ダイアログで指定された任意のコマンド行引数に追加されます。コントロール・パネルからのコマンド行引数は、それらのコマンド行引数が指定されたバージョンのすべてのJVMインスタンスに使用されます。そのため、java_arguments
パラメータでそれを完全に置き換えることはできません。
JVMコマンド行引数が指定された場合は、その要求を満たすために、Java Plug-inが別のJVMインスタンスを起動することが必要になる可能性があります。つまり、既存のJVMインスタンスがその要求を満たすような一連の正しいコマンド行引数で起動された可能性はほとんどありません。特定のアプレットを起動するために新しいJVMインスタンスを正確にいつ起動するかについての規則は、意図的に指定されないまま残されており、今後のリリースで変更が必要になる可能性があります。新しいJVMインスタンスの共有と作成についての一連の概略のガイドラインを次に示します。
既存のJVMインスタンスを起動するために使用されたコマンド行引数が、要求された引数のスーパー・セットである場合は、既存のJVMインスタンスが使用されます。
JVMインスタンスが「デフォルトの」一連のコマンド行引数(つまり、Javaコントロール・パネルでjava_arguments
なしで指定されたコマンド行引数)で起動されている場合は、java_argumentsでコマンド行引数が1つしか指定されていないアプレットであっても、このJVMインスタンスがアプレットの起動に使用されることは決してありません
。
-Xmx
は特別に処理されます。既存のJVMインスタンスがjava_arguments
を使用して、たとえば-Xmx256m
で起動されており、新しいアプレットが-Xmx128m
を要求した場合、その新しいアプレットは既存のJVMインスタンスで実行される可能性が高くなります。つまり、-Xmx
の指定は「より大きいか、または等しい」のテストで照合されます。
特定のアプレットを起動するために使用されるJVMインスタンスに「名前を付け」て、以降のアプレットにそのJVMインスタンスでの実行を「強制する」方法はありません。
特定のアプレットを、独自のJVMインスタンス内でその他のすべてのアプレットから切り離すには、「separate_jvm
」パラメータのセクションを参照してください。
特定のアプレットを起動するためのJREバージョンを指定します。
配備ツールキットを使用して、必要な場合は古いバージョンのJREを指定します。エンタープライズ環境では、古いバージョンのJREを要求する望ましい方法は、デプロイメント・ルール・セット機能を使用することです。
Java Plug-inは、アプレットごとに、アプレットでのクラス・ローダー・キャッシュの使用から抜け出るための方法を提供します。
<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300"> <PARAM name="classloader_cache" value="false"> </APPLET>
アプレットでは、classloader_cache
パラメータのデフォルト値はtrue
であり、これはクラス・ローダー・キャッシュが有効になっていることを示します。JNLPアプレットでは、クラス・ローダー・キャッシュは無効になっています。
アプレットの実行に必要とされるアクセス権のレベルを指定します。次の値が有効です。
sandbox
- アプレットはセキュリティ・サンドボックス内で実行されます。
all-permissions
- アプレットはユーザーのシステム上のリソースへのアクセスを必要とします。
default
- アクセス権のレベルは、メインJARファイル用のマニフェストに含まれるPermissions
属性によって決められます。
<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300"> <PARAM name="permissions" value="sandbox" /> </APPLET>
このパラメータを省略した場合は、default
が指定されているとみなされます。このパラメータが存在し、default
に設定されていない場合、その値は、Permissions
属性を持ついずれかのJARファイル用マニフェストに含まれるPermissions
属性の値と一致する必要があります。それ以外の場合、アプレットはブロックされます。
Javaアプリケーションで使用するファイルは、後ですぐに実行できるように特別なフォルダに格納されます。このフォルダはJavaキャッシュとも呼ばれます。20.1項「一般」で説明されているJavaコントロール・パネルの「一般」タブのサブパネル「インターネット一時ファイル」を使用すると、Javaキャッシュに格納されているファイルを表示したり、使用しているコンピュータでキャッシュが占有できるディスク領域を制御したりできます。
cache_archive
属性には、キャッシュするファイルのリストを指定します。
<param name="cache_archive" VALUE="a.jar,b.jar,c.jar">
appletタグのarchive属性と同様に、cache_archive属性のjarファイルのリストには完全なURLは指定されていませんが、常にembed
またはobject
タグに指定されているcodebaseからダウンロードされます。
Java SE 7リリース以降では、アプレットの初期化中にそのstatus
変数の値をチェックできます。このチェックは非ブロック型であり、即時にアプレットのステータスを返します。アプレットのロード中にそのステータスを明示的にチェックして適切なアクションを実行することができ、アプレット初期化の様々な段階で自動的に呼び出されるイベント・ハンドラを登録することもできます。この機能を使用するには、java_status_events
パラメータをtrue
に設定してアプレットをデプロイします。ステップ・バイ・ステップの手順や例については、Javaチュートリアルのイベント・ハンドラを使用した初期化ステータスの処理に関するレッスンを参照してください。
ユーザーはさまざまなイベントのイベント・ハンドラを登録できます。Java Plug-inソフトウェアは、アプレット・ロード処理の様々な段階でこれらのイベント・ハンドラを呼び出します。表12-2では、イベント・ハンドラを登録可能なアプレット・イベントについて説明します。
表12-2 アプレット・イベント
アプレット・イベント | イベントの発生タイミング |
---|---|
|
アプレットのステータスはREADYです。アプレットのロードが完了し、JavaScript呼出しを受け取る準備が整いました。 |
|
アプレットは停止しています。 |
|
アプレットのステータスはERRORです。アプレットのロード中にエラーが発生しました。 |
次のコード例に示すように、WebページのJavaScriptコード内でイベント・ハンドラの登録や判別を行うことができます。
// use an anonymous function applet.onLoad(function() { //event handler for ready state } // use a regular function function onLoadHandler() { // event handler for ready state } // Use method form applet.onLoad(onLoadHandler); // Use attribute form applet.onLoad = onLoadHandler; // get current event handler var handler = applet.onLoad
この項では、既存のJavaプラグイン・アプレットをJava Network Launching Protocol (JNLP)に移行する方法について説明します。次のオプションがあります。
アプレットをJava Web Startアプリケーションに移行します。
アプレットでJNLPを使用します
JNLPへの移行の利点および考慮事項について、次の項で説明します。
アプレットでJNLPを使用すると、アプレットはJava Web Startアプリケーションがアクセスできるものと同じリソースにアクセスできます。
Java Web Startアプリケーションに移行すると、Webブラウザを使わずにアプリケーションを起動できます。ユーザーがオフラインになっていたり、ブラウザにアクセスできない場合があります。デスクトップ・ショートカットでもアプリケーションを起動できるため、ユーザーはネイティブ・アプリケーションと同じ操作性を得られます。
appletタグを使用してデプロイされたアプレットは、JNLPを使用できます。JNLPファイルはjnlp_href
属性で指定されます。デプロイメントを構成するパラメータは、属性およびパラメータとして指定できます。たとえば、
<applet code="java2d.Java2DemoApplet" jnlp_href="dynamictree_applet.jnlp" width="710" height="540" > <param name="param1" value="value1"/> </applet>
Java Web Startテクノロジにはアプレットのサポートが組み込まれています。アプレットの再コンパイルを行わずに、使用しているアプレットをJava Web Startテクノロジで直接実行することが可能です。ユーザーが行うのは、JNLP applet-desc
要素を使用してアプレットのHTMLタグをJava Network Launching Protocol (JNLP)ファイルに変換することのみです。たとえば、
<resources> <jar href="SwingSet2.jar"/> </resources> <applet-desc main-class="SwingSet2Applet" name="SwingSet" width="625" height="595"> <param name="param1" value="value1"/> <param name="param2" value="value2"/> </applet-desc>
使用しているアプレットを移行する最善の方法は、それをスタンドアロンのJavaアプリケーションに書き直してから、Java Web Startテクノロジで配備することです。アプレットを書き直して結果となるアプリケーションをテストすると、変換されたアプレットが期待どおりに十分に機能することを確認でき、アプリケーションでJava Web Startの機能を利用できます。
必要とされる主な作業は、使用しているapplet
クラスをアプリケーションのmain
クラスに変換することです。アプレットのinit
およびstart
メソッドがなくなるため、かわりにアプリケーションのmain
メソッドの開始時にアプリケーションを初期化します。
移行を迅速に始めるには、main
メソッドを元のapplet
クラスに追加してから、本来ならアプレットのinit
およびstart
メソッドからそれが呼び出されるアプレット初期化コードの呼出しを開始します。main
メソッドがapplet
クラスに含まれていれば、Java Web Startテクノロジによってその起動を開始できます。その後、ゆっくりとapplet
クラスへの依存関係を削除し、それをアプリケーションのmain
クラスに完全に変換できます。
詳細は、「JNLPファイルの構文」を参照してください。
移行時に考慮すべき事項を次に示します。
Java Web Startアプリケーションは、Web ブラウザ内では実行されません。ブラウザ上でアプレットになんらかの依存関係がある場合(ブラウザを使用したJavaからJavaScriptまたはJavaScriptからJavaへの通信など)、通信コードは機能しません。影響を受けるAPIには次が含まれます。
JavaからJavaScriptへの通信用のJSObject
API (netscape.javascript.JSObject.*
)は、Java Web Startアプリケーションでは機能しません。
Java Plug-inアプレットに使用できる共通Document Object Model (DOM) API (com.sun.java.browser.dom.*
およびorg.w3c.dom.*
)は、Java Web Startアプリケーションでは使用できません。
Java Plug-inテクノロジと同様に、Java Web Startテクノロジでもスタートアップ性能を向上させるためにアプリケーションJARをキャッシュに格納します。ただし、独自のアプリケーション・コードでダウンロードされたリソースはJava Web Startテクノロジによってキャッシュされません。
Java Web Startテクノロジは、Internet Explorerのcookieストアを使用することにより、Windows上で永続cookieのサポートを提供し、cookieを扱う際の動作はIEのcookie制御により決定されます。LinuxおよびSolaris上では、Java Web Startテクノロジは独自のcookieストア実装を使用することにより、永続cookieのサポートを提供します。詳細は、Javaチュートリアルのcookieに関するトピックを参照してください。
JNLP applet-desc
要素でアプレットを配備した場合は、Java Web Startテクノロジが提供するAppletContainer
を使用してアプレットが作成されます。アプレットがApplet.getAppletContext()
を呼び出すと、Java Web Startテクノロジが提供するAppletContainerContext
が返されます。次のリストは、Java Plug-inのAppletContext
とJava Web StartのAppletContext
の間には実装におけるわずかな違いを示しています。
次のアプレット永続性APIメソッドは、Java Web Startテクノロジでは実装されません。
AppletContext.getStream(String key) AppletContext.getStreamKeys() AppletContext.setStream(String key, InputStream s)
Java Web Startアプリケーションでは、クライアント・システムでデータをローカルに格納する際にJNLP永続性サービスAPIを使用できます。詳細は、PersistenceService
インタフェースを参照してください。
AppletContext.showDocument(URL url, String target)
では、target引数がJava Web Startテクノロジによって無視されます。
AppletContext.showStatus(String status)
では、それがJava Web Startテクノロジで起動されると、アプレットを下回るJLabel
テキストが設定され、Java Web StartのAppletContainer
によってホストされます。
AppletContext.showDocument
と同様に、BasicService.showDocument
APIを使用すれば、Java Web StartアプリケーションでシステムのデフォルトWebブラウザを使用してHTMLページを表示できます。
Java Plug-inアプレットの場合:
AppletContext.showDocument(URL url) AppletContext.showDocument(URL url, String target)
Java Web Startアプリケーションの場合:
BasicService.showDocument(URL url)
詳細は、BasicService
インタフェースを参照してください。
アプレットで、次の呼出しを使用してリソースを取得した場合:
Applet.getImage(URL url) Applet.getImage(URL url, String name) Applet.getAudioClip(URL url) Applet.getAudioClip(URL url, String name) AppletContext.getAudioClip(URL url) AppletContext.getImage(URL url)
Java Web Startテクノロジでのベストプラクティスは、アプリケーションJARファイルにそれらのリソースを入れておき、JNLPClassLoader
を使用してそれらにアクセスすることです。
ClassLoader cl = this.getClass().getClassLoader(); URL url = cl.getResource(url); Image im = Toolkit.getDefaultToolkit().createImage(url);
詳細は、「JARファイルからのリソースの取得」を参照してください。
pack200 JARパック・ツールは、Java Web StartとJava Plug-inの両方のテクノロジでサポートされています。すでにアプレットJARをpack200で配備している場合は、Java Web Startテクノロジへの移行時に何も変更する必要はありません。詳細は、30.2項「Pack200で圧縮されたJARファイルの配備に関するトピック」を参照してください。
Java Plug-inテクノロジのOBJECT
タグを使用すると、Plug-in CLSID
が含まれているクライアント・マシンでJavaが使用できるかどうかを検出し、必要に応じて自動ダウンロードできます。同じサポートをJava Web Startテクノロジで使用可能にするには、Java Web Start CLSID
を使用します。詳細は、JavaチュートリアルのJREソフトウェアの存在を確認する方法に関するトピックを参照してください。
Java Web Startアプリケーションの拡張機能を配備する場合は、JNLP拡張機能プロトコル・メカニズムを使用します。詳細は、『JSR 56: Java Network Launching Protocol and API』のセクション3.8「Extension Descriptor」を参照してください。
Java Plug-inテクノロジによるJNLP拡張機能メカニズムの利点の1つは、アプリケーションの実行に使われているJREのバージョンに関係なく、インストールされた拡張機能が、システムで実行されているすべてのJava Web Startアプリケーションで利用できるようになることです。Java Plug-inテクノロジでは、同じJREバージョンで実行されているアプレットしかインストールされた拡張機能を利用できません。
署名付きJARファイルでは、Java Plug-inテクノロジと同様に、アプリケーションJARファイルに署名し、JNLPファイルによってアプリケーションが完全なアクセス権(all-permissions)で実行されるように要求できます。Java Plug-inテクノロジでは、異なる証明書でアプレットJARに署名できます。Java Web Startテクノロジでは、1つのJNLPファイルに含まれているすべてのJARファイル(jar
およびnativelib
要素)の署名には同じ証明書を使用する必要があります。これにより、起動中にユーザーに提示する証明書はJNLPファイルごとに1つで済むため、ユーザー管理が簡略化されます。異なる証明書で署名されたJARを使用する必要がある場合は、それらをコンポーネント拡張機能のJNLPファイルに入れて、メインJNLPファイルから参照できます。詳細は、『JSR 56: Java Network Launching Protocol and API』のセクション5.4「Signed Applications」とセクション4.7「Extension Resources」を参照してください。