拡張機能メカニズムのアーキテクチャ
目次
はじめに
注: オプション・パッケージは、これまで標準拡張機能として知られてきたものの新しい名称です。「拡張機能メカニズム」は、オプション・パッケージの使用をサポートする、JDKおよびJREの機能です。このドキュメントでは、オプション・パッケージを処理するためのJava(tm)プラットフォームが提供するメカニズムについて説明します。オプション・パッケージは、1つまたは複数のJARファイルにまとめられたパッケージの集まりで、Javaプラットフォームを拡張するAPIを実装します。オプション・パッケージはプラットフォームを拡張して、仮想マシンが、クラス・パスに存在しないクラスをプラットフォームのコアAPIのクラスとして検索し、ロードできるようにします。
オプション・パッケージは、プラットフォームのコアAPIを拡張するため、適切に適用する必要があります。通常はJava Community Processで定義されたインタフェースなど、適切に標準化されたインタフェースのために使用されますが、サイト全体のインタフェースに適用されることもあります。オプション・パッケージが単一または少数のアプリケーションで使用されるインタフェースに適用されることはほとんどありません。
また、インストール型オプション・パッケージで定義される記号はどのJavaプロセスでも視認できるため、必ずすべての参照可能な記号が所定の「逆順ドメイン名」および「クラス階層」の規約を守っているか気を付けて見るようにします(com.mycompany.MyClassなど)。
オプション・パッケージの実装は、Javaプログラミング言語で記述されたコードですが、まれに、プラットフォーム固有のネイティブ・コードが含まれる場合もあります。さらに、プロパティ、ローカリゼーションのカタログ、イメージ、直列化されたデータ、およびその他のリソースなど、そのオプション・パッケージに固有の各種リソースが含まれることもあります。
Internet ExplorerやNetscape Navigatorなどのブラウザでは、オプション・パッケージはJava Plug-inによってサポートされています。詳細は、「アプレット開発ガイド」を参照してください。
オプション・パッケージは、オープンで標準的なAPIを実装したものです(オプション・パッケージの例は、JavaServlet、Java3Dなど)。例外もありますが、オプション・パッケージの多くはjavax.*の名前空間に割り当てられます。
拡張機能メカニズム
アーキテクチャ
拡張機能メカニズムは、次の要素を含むように設計されています。- JARファイルにまとめたオプション・パッケージまたはアプリケーションは、ほかのJARファイルとの依存関係を宣言できるようになっています。このため、アプリケーションを複数のモジュールで構成できます。
- クラス・ローディング・メカニズムを拡張して、インストール型オプション・パッケージ(およびほかのライブラリ)からクラスを検索できるようになっています。検索に失敗すると、アプリケーションで指定したパスからクラスを検索します。
このアーキテクチャでは、アプリケーション、アプレット、およびサーブレットがそれら自体のクラス・パスを拡張できるので、それらを複数のJARファイルとしてまとめ、配置することも可能になります。
それぞれのオプション・パッケージまたはアプリケーションは、少なくとも1つのJARファイルで構成されます。JARファイルにはマニフェスト、コード、各種リソースが含まれることもあります。後述するように、このプライマリJARファイルには、他のJARファイルとの依存関係を記述するため、そのマニフェストに付加情報を含めることもできます。JDKに収録されているjarコマンド行ツールには、オプション・パッケージをひとまとめにする便利な機能があります。(jarツールの参照ページ: [Microsoft Windows] [Solaris、Linux、Mac OS X])
オプション・パッケージまたはアプリケーションは、プライマリJARファイルから参照される別のJARファイルを参照することもあります。これらのJARファイルには、JARファイルごとに独自の依存関係情報を含めることもできます。
オプション・パッケージを構成するパッケージは、オプション・パッケージの実装時には、標準的なパッケージ命名規約に従って命名する必要があります。この命名規約は「Java言語仕様」で大筋が示されていますが、ドメインの接頭辞はすべて大文字で指定するという規則はなくなりました。たとえば、COM.sun.serverというパッケージ名はcom.sun.serverとも指定できます。アプリケーションとオプション・パッケージは同じクラス・ローダーを共有する場合があるので、名前の衝突を避けるため、パッケージには一意の名前を付けることをお薦めします。
オプション・パッケージの配置
オプション・パッケージは、アプリケーションにバンドルする(バンドル型)方法と、すべてのアプリケーションで使用できるようにJREにインストールする(インストール型)方法があります。バンドル型オプション・パッケージはアプリケーションと同じコード・ベースに置かれ、ネットワーク・アプリケーション(アプレット)の場合は自動的にダウンロードされます。したがって、バンドル型オプション・パッケージは、ダウンロード型オプション・パッケージと呼ばれる場合があります。バンドル型オプション・パッケージのJARファイルのマニフェストにバージョン情報が含まれ、そのJARファイルに署名がなされている場合、ダウンロード先のJREの拡張機能ディレクトリにインストールできます。インストール型オプション・パッケージは、最初に使用されるときにロードされ、同じJREを使用するすべてのアプリケーションによって共有されます。
オプション・パッケージをまとめる場合には、JARファイルのマニフェストはベンダーおよびバージョン情報を識別するために使用されます(「パッケージのバージョンID」を参照)。
インストール型オプション・パッケージのクラスは、同じ仮想マシン上のすべてのコードによって共有されます。したがって、インストール型オプション・パッケージはそのプラットフォームの(rt.jarの)コア・クラスに似ていますが、インストール型オプション・パッケージは、後述するように、専用のクラス・ローダーと事前に構成されたセキュリティ・ポリシーを持ちます。
バンドル型オプション・パッケージのクラスは、該当アプリケーション、アプレット、またはサーブレットのクラス・ローダーだけが使用します。アプレットなどのネットワーク・アプリケーションの場合、バンドル型オプション・パッケージは必要に応じて自動的にダウンロードされます。現時点では、クラス・ローダーは特定のコード・ベースに関連付けられているので、同じコード・ベースに置かれたアプレットであれば実装(JAR)を共有できます。ただし、前述のようにバージョン情報を持ち署名されたバンドル型オプション・パッケージがJREにインストールされている場合、それらの内容は、同じJREによって動作するすべてのアプリケーションで使用可能であり、専有されるものではありません。
インストール型オプション・パッケージ
インストール型オプション・パッケージのJARファイルは、標準のローカル・コード・ソースに置かれます。
<java-home>\lib\ext [Microsoft Windows] <java-home>/lib/ext [Solaris OS, Linux]
ここで<java-home>は、ランタイム・ソフトウェアのインストール先ディレクトリ(JREのトップレベル・ディレクトリまたはJDKのjreディレクトリ)を指します。
システム・プロパティjava.ext.dirsを使用すると、インストール型オプション・パッケージを置く場所を指定できます。このプロパティには、インストール型オプション・パッケージを検索するディレクトリを指定できます。複数のディレクトリを指定する場合は、File.pathSeparatorCharで区切ります。java.ext.dirsのデフォルトの設定値は、上に示したインストール型オプション・パッケージの標準のディレクトリになっています。Java 6以降に改良されたデフォルト設定では、同じシステムにインストールされたすべてのJRE (Java 6以降)によって共有されるプラットフォーム固有のディレクトリへのパスが付けられます。
%SystemRoot%\Sun\Java\lib\ext [Microsoft Windows] /usr/java/packages/lib/ext [Linux] /usr/jdk/packages/lib/ext [Solaris OS]
さらに、インストール型オプション・パッケージは、1つ以上の共有ライブラリ(.dllファイルなど)と実行可能ファイルを含んでいます。そのあと、<arch>が表示されますが、実際には命令セット・アーキテクチャの名前、たとえばsparc、sparcv9、i386、amd64などが続きます。これらは2つの場所のいずれかにインストールされます。最初に検索されるのは次のディレクトリです。
<java-home>\bin [Microsoft Windows] <java-home>/lib/<arch> [Solaris OS, Linux]
次に検索される拡張機能ディレクトリは、Java 6以降にのみ適用されます。Javaパッケージと同様、ネイティブ・ライブラリはすべてのJava 6とそれ以降のJREによって共有されるディレクトリにインストールできます。
%SystemRoot%\Sun\Java\bin [Microsoft Windows] /usr/java/packages/lib/<arch> [Linux] /usr/jdk/packages/lib/<arch> [Solaris OS]
ネイティブ・コードが含まれるオプション・パッケージは、信頼できるコードか信頼できないコードかにかかわらず、実行時にネットワーク・コードにより仮想マシンにダウンロードすることはできません。ネイティブ・コードが含まれ、ネットワーク・アプリケーションとともにバンドルされているオプション・パッケージは、JDKまたはJREにインストールする必要があります。
デフォルトでは、この標準のディレクトリに置かれたインストール型オプション・パッケージは信頼できます。つまり、このディレクトリに置かれたインストール型拡張機能には、コア・プラットフォーム・クラス(rt.jar内のクラス)の場合と同じ特権が与えられます。このデフォルトの特権は、システム・ポリシー・ファイル(<java-home>/jre/lib/security/java.policy)で指定されていますが、適切なポリシー・ファイルのエントリ(「JDKでのアクセス権」を参照)を追加すれば、特定のオプション・パッケージにオーバーライドできます。
なお、信頼できるエンティティによりインストール型オプション・パッケージのJARファイルに署名が付けられている場合、そのオプション・パッケージには、署名を付けたエンティティに関連付けられている特権が与えられます。
オプション・パッケージのセキュリティ
インストール型オプション・パッケージのコード・ソース(<java-home>/lib/ext)には、事前に構成されたセキュリティ・ポリシーが割り当てられています。このディレクトリに置かれたJARファイルに与えられる正確な信頼度レベルは、次の標準のセキュリティ・ポリシー構成ファイルによって指定されます
<java-home>/lib/security/java.policy
デフォルトのポリシーは、インストール型オプション・パッケージが、コア・プラットフォームの一部である場合と同じように動作できるようにするためのものです。これは、インストール型オプション・パッケージがネイティブ・コードをロードするという一般的な必要性に基づいています。
Java Security Modelは、インストール型オプション・パッケージのコードが信頼できないコードから呼び出された場合のために、ある種の安全策を提供しています。しかし、オプション・パッケージのコードが特権ブロックを使用する場合は必ず、セキュリティ上の危険性がないかどうかコードを十分に確認する必要があります。
リモートからロードされるオプション・パッケージで、正常な動作のため、アクセス・チェックが行われるシステム・サービス(ファイル入出力など)を使用する必要があるものについては、信頼できるエンティティによる署名が付けられたものであるか、信頼できる場所からロードされたものでなければなりません。
Javaプラットフォームのセキュリティ機能を利用するためのオプション・パッケージやアプリケーションのコードを記述する方法の詳細については、Java セキュリティ・ドキュメントを参照してください。
関連API
Javaプラットフォームのいくつかのクラスは、次のような拡張機能メカニズムをサポートします。