クラスの検索方法 |
SDK ツール |
Java 起動ツール java は、Java 仮想マシン (VM) を起動します。 仮想マシンは、次の順序でクラスを検索してロードします。
- ブートストラップクラス - Java プラットフォームを構成するクラス。
rt.jar
とi18n.jar
内のクラスが含まれる
- 拡張機能クラス - Java 拡張機能機構を使用するクラス。 拡張機能用ディレクトリに
.jar
ファイルとしてバンドルされている
- ユーザクラス - 開発者とサードパーティにより定義された、拡張機能の機構を利用しないクラス。 これらのクラスの位置は、コマンド行で -classpath オプションを使用する (推奨) か、CLASSPATH 環境変数を使って指定する。 クラスパスの設定については、Windows または Solaris 用のページを参照
実際には、この 3 つの検索パスは 1 つのシンプルなクラスパスに結合されます。 これは、以前に使われていた「平坦な」クラスパスに似ていますが、現在のモデルには重要な相違点がいくつかあります。
- ブートストラップクラスを誤って「隠し」たり省略したりする間違いが比較的少なくなる
- 通常は、ユーザクラスの位置を指定するだけで済む。 ブートストラップクラスと拡張機能クラスは、「自動的」に検出される
- ツールのクラスは、現在は別のアーカイブ (tools.jar) に分けられており、ユーザクラスパスに含まれている場合にだけ使用できる (簡単な説明を後述する)
Java 起動ツールがブートストラップクラスを検索する方法
ブートストラップクラスは、Java 2 プラットフォームを実装しているクラスです。 ブートストラップクラスは、
jre/lib
ディレクトリのrt.jar
とi18n.jar
の 2 つのアーカイブ内に格納されています。 これらのアーカイブは、システムプロパティ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 ファイル) 内に含まれている必要があります。 拡張機能ディレクトリの位置を変更するためのオプションはありません。
Java 起動ツールがユーザクラスを検索する方法
ユーザクラスは、Java プラットフォームの上に構築されるクラスです。 ユーザクラスを探すために、起動ツールは、ユーザクラスパス (ディレクトリ、JAR アーカイブ、クラスファイルの入った ZIP アーカイブのリスト) を参照します。
クラスファイルには、そのクラスの完全指定された名前を示すサブパス名があります。 たとえば、クラス
com.mypackage.MyClass
が/myclasses
内に格納されている場合、/myclasses
はユーザクラスパス内に含まれていなければならず、そのクラスファイルへのフルパスは/myclasses/com/mypackage/MyClass.class
でなければなりません。 クラスがmyclasses.jar
という名前のアーカイブ内に格納されている場合、そのmyclasses.jar
はユーザクラスパスに含まれていなければならず、クラスファイルはアーカイブ内にcom/mypackage/MyClass.class
として格納されていなければなりません。ユーザクラスパスは文字列として指定され、Solaris ではクラスパスのエントリはコロン (
:
) で区切られ、Win32 システムではエントリはセミコロン (;
) で区切られます。 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 ファイルが SDK の
ext
サブディレクトリ内に拡張機能としてインストールされている場合は、そのファイルが定義する JAR-class-path は無視される。 拡張機能が必要とするクラスはすべて、SDK の一部であるか、それ自体が拡張機能としてインストールされていると想定される
javac および javadoc の各ツールは、2 つの異なった方法でクラスファイルを使用します。
- すべての Java アプリケーションと同様に、javac と javadoc を実行するためには、さまざまなクラスファイルをロードする必要がある
- 処理対象のソースコードを処理するために、javac と javadoc は、ソースコードで使用されているオブジェクト型の情報を取得する必要がある
ソースコードの参照を解決するために使用されるクラスファイルのほとんどは、javac と javadoc の実行に使用されるのと同じクラスファイルです。 ただし、いくつかの重要な例外があります。
- javac と javadoc はどちらも、javac または javadoc の実装とは無関係なクラスやインタフェースへの参照を解決することがしばしばある。 参照されているユーザクラスとインタフェースに関する情報は、クラスファイルまたはソースコードファイル (あるいはその両方) の形式で存在する
tools.jar
内のツールクラスは、javac と javadoc を実行するためだけに使用される。 ツールクラスは、tool.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 プラットフォームのクラスロードモデルと互換性のないものがあります。
Copyright © 2001 Sun Microsystems, Inc. All Rights Reserved. |
Java ソフトウェア |