クラスの検索方法

Java 起動ツールがクラスを検索する方法
javac と javadoc がクラスを検索する方法
クラスのロードとセキュリティーポリシー

Java 起動ツールがクラスを検索する方法

Java 起動ツール java は、Java 仮想マシン (VM) を起動します。仮想マシンは、次の順序でクラスを検索してロードします。

ブートストラップクラス - Java プラットフォームを構成するクラス。 rt.jar と他のいくつかの重要な JAR ファイル内のクラスが含まれる

拡張機能クラス - Java 拡張機能機構を使用するクラス。拡張機能用ディレクトリに .jar ファイルとしてバンドルされている

ユーザクラス - 開発者とサードパーティーにより定義された、拡張機能の機構を利用しないクラス。これらのクラスの位置は、コマンド行で -classpath オプションを使用する (推奨) か、CLASSPATH 環境変数を使って指定する。クラスパスの設定については、Windows または Solaris 用のページを参照

実際には、この 3 つの検索パスは 1 つのシンプルなクラスパスに結合されます。これは、以前に使われていた「平坦な」クラスパスに似ていますが、現在のモデルには重要な相違点がいくつかあります。

ブートストラップクラスを誤って「隠し」たり省略したりする間違いが比較的少なくなる

通常は、ユーザクラスの位置を指定するだけで済む。ブートストラップクラスと拡張機能クラスは、「自動的」に検出される

ツールのクラスは、現在は別のアーカイブ (tools.jar) に分けられており、ユーザクラスパスに含まれている場合にだけ使用できる (簡単な説明を後述する)

Java 起動ツールがブートストラップクラスを検索する方法

ブートストラップクラスは、Java 2 プラットフォームを実装しているクラスです。ブートストラップクラスは、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

2つ前のセグメントに統合

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-class-path を定義できます。ただし、パスが拡張されるのは、その JAR ファイルからクラスをロードしている間だけです。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 または Solaris 用の javac ドキュメントで説明されています。

デフォルトでは、javac と javadoc は、ユーザクラスパスからクラスファイルとソースコードファイルの両方を検索します。-sourcepath オプションが指定されている場合、javac と javadoc は、指定されたソースファイルパスのソースファイルだけを検索します。ただし、クラスファイルは同様にユーザークラスパスから検索されます。

クラスのロードとセキュリティーポリシー

クラスまたはインタフェースを使用するためには、クラスローダでロードする必要があります。特定のクラスローダの使い方により、そのクラスローダに関連するセキュリティーポリシーが決定されます。

プログラムでは、クラスローダオブジェクトの loadClass メソッドを呼び出すことにより、クラスまたはインタフェースをロードすることができます。ただし、通常、プログラムは単に参照することによってクラスやインタフェースをロードします。クラスやインタフェースを参照すると、内部クラスローダが呼び出されます。内部クラスローダは、セキュリティーポリシーを拡張機能とユーザクラスに適用することができます。セキュリティーポリシーが有効になっていない場合は、どのクラスも「信頼できる」と判断されます。セキュリティーポリシーが有効な場合でも、ブートストラップクラスにはセキュリティーポリシーは適用されず、常に「信頼できる」とみなされます。

セキュリティーポリシーが有効な場合、セキュリティーポリシーは、システムポリシーファイルとユーザポリシーファイルによって設定されます。Java 2 SDK には、システムポリシーファイルが組み込まれています。このポリシーファイルは、拡張機能クラスは「信頼できる」状態として認可し、ユーザクラスには基本的な制限を課します。

セキュリティーポリシーの設定と有効化については、「セキュリティー」を参照してください。

注: Java 1.1 プラットフォームで使われていたセキュリティープログラミング技法の中には、Java 2 プラットフォームのクラスロードモデルと互換性のないものがあります。

Java Software