クラスの検索方法
Java起動ツールがクラスを検索する方法
Java起動ツールjavaは、Java仮想マシンを起動します。仮想マシンは、次の順序でクラスを検索してロードします。
- ブートストラップ・クラス - Javaプラットフォームを構成するクラス。
rt.jarとその他のいくつかの重要なJARファイル内のクラスが含まれる。 - 拡張機能クラス - Java拡張機能メカニズムを使用するクラス。拡張機能用ディレクトリに
.jarファイルとしてバンドルされている。 - ユーザー・クラス - 開発者とサード・パーティにより定義された、拡張機能メカニズムを利用しないクラス。これらのクラスの位置は、コマンド行で-classpathオプションを使用する(推奨)か、CLASSPATH環境変数を使って指定する。(WindowsまたはUnixの「クラス・パスの設定」を参照)。
実際には、この3つの検索パスは1つのシンプルなクラス・パスに結合されます。これは、以前に使われていた「平坦な」クラス・パスに似ていますが、現在のモデルには重要な相違点がいくつかあります。
- ブートストラップ・クラスを誤って「隠し」たり省略したりする間違いが比較的少なくなる。
- 通常は、ユーザー・クラスの位置を指定するだけで済む。ブートストラップ・クラスと拡張機能クラスは、「自動的」に検出される。
- ツールのクラスは、現在は別のアーカイブ(tools.jar)に分けられており、ユーザー・クラス・パスに含まれている場合にだけ使用できる(簡単な説明を後述する)。
Java起動ツールがブートストラップ・クラスを検索する方法
ブートストラップ・クラスは、Java 2 Platformを実装しているクラスです。ブートストラップ・クラスは、jre/libディレクトリのrt.jarとその他のいくつかのJARファイルに格納されています。これらのアーカイブは、システム・プロパティsun.boot.class.pathに格納されているブートストラップ・クラス・パスの値によって指定されます。このシステム・プロパティは参照専用なので、直接修正しないでください。
ブートストラップ・クラス・パスの再定義が必要になることはほとんどありません。まれに、別のコア・クラスのセットを使用する必要が生じた場合には、非標準オプション-Xbootclasspathを使って行うことができます。
Java 2 SDKツールを実装するクラスは、ブートストラップ・クラスとは別のアーカイブに分けられています。ツール・アーカイブは、SDKの/lib/tools.jarファイルです。開発ツールは、起動ツールを呼び出すときに、このアーカイブをユーザー・クラス・パスに追加します。ただし、この追加後のユーザー・クラス・パスは、ツールを実行するためだけに使用されます。ソース・コードを処理するツール(javacとjavadoc)は、追加後のクラス・パスではなく、元のクラス・パスを使用します。(詳細は、このあとの「javacとjavadocがクラスを検索する方法」を参照してください)。
Java起動ツールが拡張機能クラスを検索する方法
拡張機能クラスは、Javaプラットフォームを拡張するクラスです。拡張機能ディレクトリjre/lib/ext内の.jarファイルはすべて拡張機能とみなされ、Java拡張機能フレームワークを使ってロードされます。拡張機能ディレクトリ内の圧縮されていないクラス・ファイルは、見つけることができません。.jarファイル(または.zipファイル)内に含まれている必要があります。拡張機能ディレクトリの位置を変更するためのオプションはありません。
jre/lib/extディレクトリに複数の.jarファイルが含まれており、次のように、これらのファイルに同じ名前のクラスが含まれている場合、
smart-extension1_0.jar contains class smart.extension.Smart
smart-extension1_1.jar contains class smart.extension.Smart
実際にロードされるクラスは未定義になります。
Java起動ツールがユーザー・クラスを検索する方法
ユーザー・クラスは、Javaプラットフォーム上に構築されるクラスです。ユーザー・クラスを探すために、起動ツールは、ユーザー・クラス・パス (クラス・ファイルの入ったディレクトリ、JARアーカイブ、ZIPアーカイブのリスト)を参照します。
クラス・ファイルは、そのクラスの完全修飾名が反映されたサブパス名を持ちます。たとえば、クラスcom.mypackage.MyClassが/myclassesに格納されている場合、/myclassesはユーザー・クラス・パスに含まれている必要があり、クラス・ファイルへのフル・パスは/myclasses/com/mypackage/MyClass.classでなければいけません。クラスがmyclasses.jarという名前のアーカイブ内に格納されている場合、myclasses.jarはユーザー・クラス・パスに含まれている必要があり、クラス・ファイルはアーカイブ内にcom/mypackage/MyClass.classとして格納されていなければいけません。
ユーザー・クラス・パスは文字列として指定され、Solarisではクラスパス・エントリはコロン(:)で区切られ、Microsoft Windowsシステムではエントリはセミコロン(;)で区切られます。Java起動ツールは、ユーザー・クラス・パス文字列をシステム・プロパティjava.class.pathに書き込みます。この値は、次のいずれかのソースから取得されます。
- デフォルト値「
.」。ユーザー・クラス・ファイルは、現在のディレクトリ内(パッケージ内の場合、その下)のすべてのクラス・ファイル。 - CLASSPATH環境変数の値。デフォルト値をオーバーライドする。
- -cpまたは-classpathコマンド行オプションの値。デフォルト値とCLASSPATH値の両方をオーバーライドする。
- -jarオプションで指定されたJARアーカイブ。他のすべての値をオーバーライドする。このオプションを使用する場合、すべてのユーザー・クラスは指定されたアーカイブからのものである必要がある。
Java起動ツールがJAR-class-pathクラスを検索する方法
JARファイルには通常、「マニフェスト」(そのJARの内容をリストしたファイル)が含まれます。マニフェストには、クラス・パスをさらに拡張する(そのJARファイルからクラスをロードしているときのみ)、JAR-class-pathを定義できます。JAR-class-pathによってアクセスされるクラスは、次の順序で検索されます。
- 一般的に、JAR-class-pathエントリによって参照されるクラスは、JARファイルの一部であるかのように検索される。JAR-class-path内のJARファイルは、クラス・パス内でそのJARファイルより前にあるエントリのあと、かつ、そのJARファイルよりあとにあるエントリの前に検索される。
- ただし、JAR-class-pathが、すでに検索されたJARファイル(たとえば、拡張機能、またはクラス・パス内でそれより前に記述されているJARファイル)を指している場合は、そのJARファイルが再度検索されることはない。(この最適化により効率が向上し、循環検索が回避される。)このようなJARファイルは、クラス・パスの前の方で認識された時点で検索される。
- JARファイルが拡張機能としてインストールされている場合は、そのJARファイルによって定義されるすべてのJAR-class-pathは無視される。拡張機能が必要とするクラスはすべて、SDKの一部であるか、それ自体が拡張機能としてインストールされていると見なされる。
javacとjavadocがクラスを検索する方法
javacおよびjavadocの各ツールは、2つの異なった方法でクラス・ファイルを使用します。
- Javaアプリケーションと同様に、javacとjavadocを実行するためには、さまざまなクラス・ファイルをロードする必要がある。
- 処理対象のソース・コードを処理するために、javacとjavadocは、ソース・コードで使用されているオブジェクト型の情報を取得する必要がある。
ソース・コード参照を解決するために使用されるクラス・ファイルのほとんどは、javacとjavadocの実行に使用されるのと同じクラス・ファイルです。ただし、いくつかの重要な例外があります。
- javacとjavadocはどちらも、javacまたはjavadocの実装とは無関係なクラスやインタフェースへの参照を解決することがしばしばある。参照されているユーザー・クラスとインタフェースに関する情報は、クラス・ファイルまたはソース・コード・ファイル(あるいはその両方)の形式で存在する。
tools.jar内のツール・クラスは、javacとjavadocを実行するためだけに使用される。ツール・クラスは、tools.jarがユーザー・クラス・パス内にある場合を除いて、ソース・コード参照を解決するためには使用されない。- プログラマは、代替Javaプラットフォーム実装を使って、ブート・クラスまたは拡張機能クラス参照を解決したい場合がある。javacとjavadocはどちらも、-bootclasspathおよび-extdirsオプションでこれをサポートする。これらのオプションを使用しても、javacツールまたはjavadocツール自体の実行に使用されるクラス・ファイル・セットは変更されない。
参照されるクラスがクラス・ファイルとソース・ファイルの両方で定義されている場合、javadocは常にソース・ファイルを使用します(javadocはソース・ファイルをコンパイルしない)。同じ状況の場合に、javacはクラス・ファイルを使用しますが、古くなったと判断されるクラス・ファイルは自動的に再コンパイルします。自動再コンパイルの規則については、WindowsまたはUnix用のjavacドキュメントで説明されています。
デフォルトでは、javacとjavadocは、ユーザー・クラス・パスからクラス・ファイルとソース・コード・ファイルの両方を検索します。-sourcepathオプションが指定されている場合、javacとjavadocは、指定されたソース・ファイル・パスでのみソース・ファイルを検索します。ただし、クラス・ファイルは同様にユーザー・クラス・パスから検索されます。
クラスのロードとセキュリティ・ポリシー
クラスまたはインタフェースを使用するためには、クラス・ローダーでロードする必要があります。特定のクラス・ローダーの使い方により、そのクラス・ローダーに関連するセキュリティ・ポリシーが決定されます。
プログラムでは、クラス・ローダー・オブジェクトのloadClassメソッドを呼び出すことにより、クラスまたはインタフェースをロードできます。ただし通常は、プログラムは単に参照することによってクラスやインタフェースをロードします。これにより内部クラス・ローダーが呼び出されます(セキュリティ・ポリシーを拡張機能およびユーザー・クラスに適用できます)。セキュリティ・ポリシーが有効になっていなかった場合でも、すべてのクラスが「信頼」されます。セキュリティ・ポリシーが有効な場合でも、ブートストラップ・クラスには適用されません(常に「信頼」されます)。
有効になっているときは、セキュリティ・ポリシーはシステムおよびユーザー・ポリシー・ファイルによって設定されます。Java 2 SDKはシステム・ポリシー・ファイルをインクルードします(拡張機能クラスに「信頼」ステータスを付与し、ユーザー・クラスに基本的な制限を適用します)。
セキュリティ・ポリシーの有効化または設定については、「セキュリティ機能」を参照してください。
注: Java 1.1プラットフォームで使われていたセキュリティ・プログラミング技法の中には、Java 2 Platformのクラス・ロード・モデルと互換性のないものがあります。