オプション・パッケージは、Javaクラスとそれに関連するネイティブ・コードのパッケージです。拡張機能を使用することにより、アプリケーションの開発者はコア・プラットフォームの機能を拡張できます。拡張機能メカニズムにより、ブートストラップ・クラスとほとんど同じようにJava仮想マシン(VM)からオプション・パッケージ・クラスを利用できます。ブートストラップ・クラスは、コア・プラットフォームを実装しているクラスであり、jre/lib/rt.jarおよび他のいくつかの重要なjarファイルにあります。これらには、java.lang、java.ioなどの公開APIのクラス、およびプラットフォームの国際化およびローカリゼーションの機能をサポートするクラスが格納されます。ブートストラップ・クラスと同様に、オプション・パッケージのクラスはクラス・パスに置く必要はありません。拡張機能メカニズムにより、必要なオプション・パッケージがJava 2 Runtime EnvironmentまたはJDKにインストールされていない場合は、指定されたURLから取得することもできます。
オプション・パッケージは、JARファイルの形で提供され、すべてのJARファイルはオプション・パッケージになり得ます。JARファイルがオプション・パッケージの役割を果たすのは、次の2つの場合です。
VMは、ある名前のクラスを探すとき、最初にブートストラップ・クラスを検索します。ブートストラップ・クラスの中に目的のクラスがない場合は、次にインストール型オプション・パッケージからそのクラスを検索します。ブートストラップ・クラスからもインストール型オプション・パッケージからも見つからない場合は、アプリケーションまたはアプレットが参照しているダウンロード型オプション・パッケージを検索します。ブートストラップ・クラスとオプション・パッケージ・クラスのどちらでもクラスを検索できない場合は、VMはクラス・パスだけを検索します。
非推奨: インストールされたオプション・パッケージのサポートは非推奨になりました。今後のリリースで削除される可能性があります。
インストール型オプション・パッケージは、次のディレクトリに置かれたJARファイルです。
lib/ext
(JRE内)jre/lib/ext
(JDK内)このディレクトリにJARファイルを置いておけば、CLASS PATHに明示的に含めなくても、中に含まれるクラスをブートストラップ・クラスの一部であるかのようにアプレットおよびアプリケーションから使用できます。
インストール型オプション・パッケージのネイティブ・コード・バイナリは、存在する場合には次のディレクトリに置きます
jre\bin
(Microsoft Windows)jre/lib/<arch>
(Solarisオペレーティング環境)<arch>
は、Solarisプロセッサ・アーキテクチャで、sparc
かi386
です。また、ネイティブ・ライブラリは、Microsoft WindowsとSolarisオペレーティング環境の両方でjre/lib/ext/<arch>ディレクトリに置かれます。Microsoft Windowsシステムでは<arch>はi386です。jre/lib/ext/<arch>ディレクトリは、jre\binまたはjre/lib/<arch>の後に検索されます。
Java VMは、特定の名前のクラスを探すとき、最初に実行環境でそのクラスを検索します。標準の実行環境のクラスから検出できなかった場合は、VMはオプション・パッケージのディレクトリに置かれているすべてのJARファイルから検索します。
インストール型オプション・パッケージとなる特別なJARファイルや、それに含まれるクラスがあるわけではありません。jre/lib/ext
に置かれることによってインストール型オプション・パッケージとなります。
インストール型オプション・パッケージのJARファイルのマニフェスト属性には、そのオプション・パッケージ・クラスを使うアプレットで利用できるバージョンとベンダーの情報が指定されている必要があります。バージョンとベンダーの情報を指定する属性については、「オプション・パッケージのバージョン管理」で説明します。マニフェストの例を次に示します。
Manifest-version: 1.0 Extension-Name: javax.extension Specification-Version: 1.0 Specification Vendor: Oracle Corporation. Implementation-Vendor: Oracle Corporation. Implementation-Vendor-Id: com.sun Sealed: true
Java Plug-inでは、アプレットの実行時にこのバージョンとベンダーの情報を使って、アプレットに必要なオプション・パッケージがインストールされていること、最新のバージョンであること、アプレットに適したベンダーのオプション・パッケージであることが確認されます。インストールされていない場合、またはインストールが不正な場合は、適切なオプション・パッケージのダウンロードを要求するプロンプトが表示されます。詳細は、「オプション・パッケージのバージョン管理」を参照してください。
目的のクラスがシステム・クラスからもインストール型オプション・パッケージ内のクラスからも見つからない場合は、ダウンロード型オプション・パッケージ内のクラスが検索されます。
ダウンロード型オプション・パッケージは、別のJARファイルのマニフェスト内のClass-Pathヘッダー・フィールドで指定されるJARファイルです。ダウンロード型オプション・パッケージのクラスは、参照するJARファイルのクラスで使用されます。あるJARファイルにアプレットが含まれていて、そのJARファイルのマニフェストで、そのアプレットのオプション・パッケージとなるJARファイル(複数の場合もあり)を参照しているというのが典型的な例です。同様に、オプション・パッケージ同士で互いに参照し合う場合もあります。
Class-Pathヘッダーの例を次に示します。
Class-Path: servlet.jar infobus.jar acme/beans.jar
この場合、ファイルservlet.jar
、infobus.jar
、およびacme/beans.jar
に含まれるクラスが、マニフェストにこのヘッダーが含まれるJARファイルのクラスのオプション・パッケージになります。Class-PathフィールドにURLを指定した場合、そのURLは、アプレットまたはアプリケーションが含まれるJARファイルのURLからの相対URLになります。
インストール型オプション・パッケージと違って、ダウンロード型オプション・パッケージとなるJARファイルが置かれる位置には何の意味もありません。ダウンロード型オプション・パッケージは、特定の場所に置かれるからではなく、ほかのJARファイルのマニフェストのClass-Pathヘッダーの値として指定されるからオプション・パッケージなのです。
インストール型オプション・パッケージとダウンロード型オプション・パッケージのもう1つの違いは、JARファイルに含まれているアプレットやアプリケーションだけがダウンロード型オプション・パッケージを利用できるという点です。JARファイルに含まれていないアプレットやアプリケーションは、ダウンロード型オプション・パッケージを参照するマニフェストを持ちません。
VMは、特定のクラスを探すとき、最初にシステム・クラスとインストール型オプション・パッケージを検索します。目的のクラスがシステム・クラスからもインストール型オプション・パッケージ内のクラスからも見つからない場合は、アプリケーションまたはアプレットのマニフェストで参照しているダウンロード型オプション・パッケージを検索します。目的のクラスがインストール型オプション・パッケージの中から見つかった場合は、アプレットやアプリケーションのマニフェスト・ファイルでダウンロード型オプション・パッケージを参照していても、ダウンロード型オプション・パッケージはダウンロードされません。
拡張機能メカニズムでは、ダウンロード型オプション・パッケージはJREまたはJDKのディレクトリ構造にインストールされません。ダウンロード型オプション・パッケージは、ダウンロードされてもインストール型オプション・パッケージにはなりません。
ダウンロード型オプション・パッケージの場合、インストール型オプション・パッケージとは異なり、ネイティブ・コードを含むことはできません。