Java SE 6 における Java Web Start の拡張機能

「policy」および「check」属性を持つ、新しい <update> 要素がサポートされました。update 要素には、Java Web Start が Web 上で更新をチェックする方法、および起動前に更新が入手可能であることがわかった場合の動作に関するアプリケーション設定を指定します。
以前のバージョンの Java Web Start では、<offline-allowed> 要素がオーバーロードされた場合、次の 2 つの点が明らかになりました。1 つは、「オフライン」モードでのアプリケーション実行が許可されたこと (アプリケーションをオフラインモードで実行するには、コマンド行に「-offline」引数を追加するか、キャッシュビューアを使用する)、もう 1 つは、アプリケーション (オフラインモードで実行されていない場合) の起動前に、更新のチェックがタイムアウトした可能性があることです。更新のチェックがタイムアウトした場合、アプリケーションはキャッシュから起動され、更新のチェックがバックグラウンドで続行されます。
6.0 では、<update> 要素および check 属性の登場に伴い、<offline-allowed> 要素は後者の意味を持たなくなりました。デフォルト値は <update check="timeout"/> で、この動作は以前のバージョンで <offline-allowed> を指定した場合と同じです。以前に <offline-allowed> を省略した場合の動作を再現するには、<update check="always"/> を指定する必要があります。バックグラウンドで更新をチェックしながら、キャッシュからの即時起動を常に実行する場合は、3 番目の値 <update check="background"/> を指定できます。2 番目の属性「policy」を使用して、アプリケーションの起動前に更新が入手可能であることが判明している場合の動作を指定します。常に更新を取得することも、ユーザーに指定を求めるようにすることもできます。policy 属性値には、「always」(デフォルト)、「prompt-update」、「prompt-run」のいずれかを指定できます。

以前のバージョンでは、API に引数として渡すことのできる URL は、API の種類にかかわらず、実行中のアプリケーションの jnlp ファイルに記述されたリソースへの URL に限定されていました。この制限が変更され、署名および信頼されたコードに関しては制限がなくなりました。また、信頼されないコードに対する制限は、jnlp ファイルへの記述に基づくものではなく、同じコードベースに基づくものになりました。
さらに、jnlp ファイルへの URL 自体が許可されるようになったため、DownloadService.removeResource() の呼び出しを使って、キャッシュからアプリケーション全体を削除したり、DownloadService.loadResource() を使ってアプリケーションをインポートしたりすることが可能になりました。
この変更により、どのような jnlp ファイルにもリストされていないリソースをアプリケーションで使用できるようになります。たとえば、ロケール設定を en_xx に決定すれば、使用可能なリソース jar を jnlp ファイルに記述しなくても、アプリケーションは DownloadService を使って resources_en_xx.jar をロードできます(サポートするロケールを、jnlp ファイルを変更せずに動的に追加することが可能)。

別の重要な仕様変更は、サンドボックスの定義の明確化です。これは、デフォルトのサンドボックスのみを対象としており、その実装ではサンドボックスの許可しない操作を許可するようユーザーに自由に求めることができます。1.5.0 では、印刷に関してこれが実現されていました。つまり、awt 内の通常の印刷 api を使用するだけで、サンドボックスを展開してアプリケーションからプリンタへのアクセスを許可することができました (ユーザーが同意した場合)。6.0 では、これがソケット接続でも可能になりました。このため、信頼されないアプリケーションが url への接続を試みた場合でも、ユーザーは接続を許可するよう求められます。

Java Web Start Version 6.0 以降でのみ使用される jnlp ファイルでは、<java> 要素を使用して <j2se> タグを置き換えることができます (この主な理由は Java Platform Standard Edition がもはや j2se とは呼ばれないため)。下位互換性を維持するため、<j2se> タグの機能は引き続き有効です。<java> 要素は、<j2se> 要素と同一です。

Java Web Start アプリケーションとファイル拡張子および mime タイプとの関連付けの作成時に、アプリケーション用のデフォルトアイコンを使用するのではなく、関連付けごとに別個のアイコンを指定できるようになりました。また、説明も指定できます。

JNLPClassLoader が、URLClassLoader を拡張するように書き換えられました。これには、いくつかの強力な利点があります。 
まず、Jar インデックスが完全にサポートされます。複数の jar ファイルが存在し、すべての jar ファイルをインデックス化する jar メインファイル内に jar インデックスを作成する場合、追加する各 jar に遅延のマークを付けて、内部のリソースまたはクラスが参照されるまでダウンロードされないようにできます。これにより、以前の不要な部分およびパッケージ要素に不要のマークが付けられ、遅延 jar が使用に先立ってダウンロードされないことが保証されます。
第 2 に、JNLPClassLoader が URLClassLoader を拡張するようになったため、アプリケーションは getURLs() を呼び出して jnlp ファイル内に記述されている jar 要素 (または jnlp ファイルに記述されていなくても、DownloadService API を使用してダウンロードされた jar 要素、前述の説明を参照) の一覧を取得できます。
最後に、ClassLoader.getResource() の呼び出しで返される URL が、ネット上の項目の適切な JAR URL になります。以前のバージョンでは、この返される URL はキャッシュ内のファイル url 項目の jar url でした。URLClassLoader を拡張することにより、キャッシュされた場所 (存在する場合) は意味がなくなり、Java Web Start がキャッシュなしで動作することが可能になりました。

Java Web Start では、2 つのアイコン形式「.png」および「.ico」が新たにサポートされます。これにより、指定したアイコンを、用途に応じて異なる形式に変換する必要がなくなります。また、kind="shortcut" も指定できるようになり、Java Web Start は幅と高さのヒント情報を参照するようになりました。たとえば、次のように指定した場合のことを考えてみましょう。
<icon kind="shortcut" href="menushortcut.ico" width="16" height="16"/>
<icon kind="shortcut" href="desktopshortcut.ico" width="32" height="32"/>
この場合、作成されたデスクトップおよびメニューショートカットすべてで、別個のイメージを指定できます (注:Java Web Start の使用するアイコンサイズは、デスクトップショートカットの場合は 32X32、メニューショートカットの場合は 16X16 である)。

Windows の「プログラムの追加と削除」内の Java Web Start アプリケーション用エントリに、jnlp ファイルの情報ブロックから取得した発行元、発行元の Web サイト、インストール日付、およびアプリケーションアイコンが含まれるようになりました。

Java Web Start により作成されたデスクトップショートカット用に、jnlp ファイル内の <description> 要素を使って、アプリケーションの説明を含むツールヒントが生成されるようになりました。

JnlpDownloadServlet に $$hostname と $$site の両方のマクロが含まれるようになりました。拡張により、$$hostname マクロにはホスト名が含められます。$$site マクロには、Web サイトアドレスが WAR コンテキスト部分なしで含められます。

セキュリティー保護された vm 引数とプロパティーの最新のリストについては、開発者ガイドを参照してください。

Java Web Start と Java Plug-in 共通の拡張機能

Java Web Start と Java Plug-in で表示されるすべてのダイアログおよび画面が、User Experience チームの協力のもとに再設計され、よりユーザーフレンドリーで、直感的かつ使いやすいものになりました。

Java Web Start と Java Plug-in 間で、キャッシュメカニズムおよびダウンロードエンジン全体が再設計および統合されました。 
これにより、Java Plug-in で利用できた機能が Java Web Start で新たに利用可能になり、Java Web Start で利用できた機能が Java Plug-in で新たに利用できるようになりました。

注:キャッシュ形式については全体が変更されたため、以前のものとは互換性がなくなりました。キャッシュ形式が以前のままであることを前提とする既存のコードは、Java Web Start 用であれ、Java Plug-in 用であれ、動作しません。Java Web Start キャッシュ内の既存のアプリケーションは、Java Web Start アプリケーションの初回実行時またはキャッシュビューアの起動時 (「javaws -viewer」を使用) にアップグレードされ、新規キャッシュ形式に変換されます。同様に、システムキャッシュは、Java Web Start をシステムモードで最初に実行したとき、または「javaws -system」を起動したときにアップグレードされ、新しい形式に変換されます。

Java 6 の AWT で追加された新しいモーダリティー機能を使用することで、アプリケーションにモーダルダイアログが表示されている場合でも、Java コンソールとの対話処理を実行できるようになりました。

Java Web Start および Java Plug-in は、証明書の検証用に CRL (Certificate Revocation Lists) および OCSP (Online Certificate Status Protocol) をサポートしています。

Java コントロールパネルに、デフォルトの SSL ハンドシェークプロトコルを選択するオプションが追加されました。
デフォルトでは SSLv3 および SSLv2 が設定されますが、あとでユーザーや企業が TSL に変更できます。





Copyright © 1993, 2013, Oracle and/or its affiliates. All rights reserved.