2 クラス・パスの設定

形式

クラス検索パス(クラス・パス)は、JDKツールを呼び出すときに-classpathオプションを付ける(推奨される方法)か、CLASSPATH環境変数を設定して設定できます。 -classpathオプションが推奨されているのは、アプリケーションごとに個別に設定できるので、ほかのアプリケーションに影響を与えたり、ほかのアプリケーションからこの値が変更されたりすることがないためです。

sdkTool -classpath classpath1;classpath2...

set CLASSPATH=classpath1;classpath2...

sdkTool

コマンド行ツール(java、javac、javadoc、aptなど)です。 リストについては、「JDK Tools and Utilities」を参照してください。
http://docs.oracle.com/javase/jp/8/technotes/tools/index.html

classpath1:classpath2

JAR、zipまたはクラス・ファイルへのクラス・パスです。 各クラス・パスは、クラス・パスに何を設定するかに応じて、次に示すように、ファイル名かディレクトリのどちらかで終わるようにしてください。

• クラス・ファイルを含むJARまたはzipファイルの場合、クラス・パスはzipまたはJARファイルの名前で終わります。

• 名前のないパッケージ内のクラス・ファイルの場合、クラス・パスはクラス・ファイルが含まれるディレクトリで終わります。

• 名前付きのパッケージ内のクラス・ファイルの場合、クラス・パスはルート・パッケージ(完全指定のパッケージ名の先頭パッケージ)が含まれるディレクトリで終わります。

複数のパス・エントリは、Windowsでは等号(=)の前後に空白文字を入れずにセミコロンで区切られ、Oracle Solarisではコロンで区切られます。

デフォルトのクラス・パスは、現在のディレクトリです。 このデフォルトは、CLASSPATH変数を設定したり、-classpathコマンド行オプションを使用したりするとオーバーライドされます。そのため、検索パスに現在のディレクトリを含める場合には、新しい設定にドット(.)を含める必要があります。

ディレクトリまたはアーカイブ(.zipまたはJARファイル)でも、アスタリスク(*)ワイルドカード文字でもないクラス・パスのエントリは無視されます。

説明

クラス・パスはJDKツールおよびJavaアプリケーションに対して、拡張機能やJavaプラットフォームの一部ではないサード・パーティ製のクラスおよびユーザー定義のクラスを探す位置を通知します。 「The Extension Mechanism」を参照してください。
http://docs.oracle.com/javase/jp/8/technotes/guides/extensions/index.html

クラス・パスでは、javacコンパイラでコンパイルしたすべてのクラスが検出される必要があります。 それらのクラスを簡単に検出できるように、デフォルトは現在のディレクトリになっています。

JDK、JVM、およびその他のJDKツールでは、Javaプラットフォーム(ブートストラップ)のクラス、拡張機能のクラス、そしてクラス・パスという順序でクラスが検索されます。 検索方法の詳細は、「How Classes Are Found」を参照してください。
http://docs.oracle.com/javase/jp/8/technotes/tools/findingclasses.html

ほとんどのアプリケーションのクラス・ライブラリで、拡張機能メカニズムが使用されています。 クラス・パスを設定する必要があるのは、(a)現在のディレクトリまたはそのサブディレクトリ内にないクラスや、(b)拡張機能メカニズムによって指定された位置にないクラスをロードする必要がある場合のみです。

以前のバージョンのJDKをアップグレードする場合は、不要になったCLASSPATH設定が起動設定に含まれていることがあります。 このため、classes.zipなど、アプリケーション固有ではない設定は、すべて削除する必要があります。 Java仮想マシン(JVM)を使用するサード・パーティ製アプリケーションの一部は、使用するライブラリをインクルードするようにCLASSPATH環境変数を変更できます。 このような設定は残しておいてもかまいません。

クラス・パスを変更するには、JVMまたは他のJDKツールを呼び出すときに一部のJavaコマンドの-classpathまたは-cpオプションを使用するか、またはCLASSPATH環境変数を使用します。 「JDKコマンドのクラス・パス・オプション」を参照してください。 CLASSPATH環境変数を設定するよりも、-classpathオプションを使用することをお薦めします。アプリケーションごとに個別に設定できるので、他のアプリケーションに影響を与えたり、他のアプリケーションからこの値が変更されたりすることがないためです。 「CLASSPATH環境変数」を参照してください。

クラスは、ディレクトリ(フォルダ)またはアーカイブ・ファイルに格納できます。 Javaプラットフォームのクラスは、rt.jarに格納されています。 アーカイブの詳細およびクラス・パスの機能については、「クラス・パスとパッケージ名」を参照してください。

ノート: 以前のJDKソフトウェア・リリースの一部では、デフォルトのクラス・パスに<jdk-dir>/classesというエントリが含まれています。 このディレクトリは、JDKソフトウェアが使用するためのものです。アプリケーションのクラスのためには使用しないでください。 アプリケーションのクラスは、JDKのディレクトリ階層ではない、外部のディレクトリに置いてください。 そうすれば、新しいJDKをインストールしたときに、アプリケーションのクラスを再インストールする必要がなくなります。 以前のリリースとの互換性を確保するため、<jdk-dir>/classesディレクトリをクラス・ライブラリとして使用するアプリケーションも、現在のリリースでは実行できます。ただし、将来のリリースでも実行できるという保証はありません。

JDKコマンドのクラス・パス・オプション

java、jdb、javac、javahおよびjdepsコマンドには、ツールの実行中にCLASSPATH環境変数で指定されたパス(複数可)を置き換える-classpathオプションがあります。

-classpathオプションを使用すると、他のアプリケーションに影響を与えずに、各アプリケーションが必要なクラス・パスを設定できるため、クラス・パスの設定を変更する際は、このオプションを使用することをお薦めします。javaコマンドには、-classpathの省略形である-cpオプションもあります。

ごく特殊なケースのために、javaおよびjavacコマンドには、ツール自体のクラス・ライブラリ検索用パスを変更するためのオプションがあります。 ほとんどのユーザーはこれらのオプションを使用する必要がありません。

CLASSPATH環境変数

「JDKコマンドのクラス・パス・オプション」で説明したように、-classpathコマンド行オプションはCLASSPATH環境変数よりも優先されます。 ただし、CLASSPATH環境変数を使用することにした場合のために、このセクションでは、その環境変数を設定およびクリアする方法について説明します。

set CLASSPATH=path1;path2
...

set CLASSPATH=

クラス・パスのワイルドカード

ベース名のワイルドカード文字(*)を含むクラス・パスのエントリは、ディレクトリ内の拡張子.jarまたは.JARを持つすべてのファイルのリストを指定したものと同等であるとみなされます。 たとえば、クラス・パスのエントリmydir/*はmydirというディレクトリ内のすべてのJARファイルを指定します。 *で構成されるクラス・パスのエントリは、現在のディレクトリ内のすべてのjarファイルのリストに展開されます。 ファイルは、隠されている(名前が「.」で始まる)かどうかに関係なく考慮されます。

アスタリスク(*)を含むクラス・パスのエントリは、クラス・ファイルには一致しません。 単一のディレクトリmydir内でクラス・ファイルとJARファイルの両方に一致するには、mydir:mydir/*またはmydir/*:mydirを使用します。 選択された順序により、mydir内のクラスおよびリソースがmydir内のJARファイルの前に(またはその逆で)ロードされるかどうかが決まります。

サブディレクトリは再帰的に検索されません。 たとえば、mydir/*ではmydir内のJARファイルのみを検索し、mydir/subdir1、mydir/subdir2などは検索しません。

ディレクトリ内のJARファイルが展開されたクラス・パスで列挙される順序は指定されず、プラットフォームにより、あるいは同じマシン上でも時間によって異なる場合があります。 うまく構成されたアプリケーションは、特定の順序に依存しないようにすべきです。 特定の順序が必要な場合は、クラス・パスでJARファイルを明示的に列挙できます。

ワイルドカードの展開は早期に行われ、クラスのロード処理自体の間ではなく、プログラムのmainメソッドの呼出しの前に行われます。 ワイルドカードを含む入力クラス・パスの各要素は、指定したディレクトリ内のJARファイルを列挙して生成された要素のシーケンス(空の場合もある)によって置き換えられます。 たとえば、ディレクトリmydirにa.jar、b.jarおよびc.jarが含まれる場合、クラス・パスmydir/*はmydir/a.jar:mydir/b.jar:mydir/c.jarに展開され、文字列はシステム・プロパティjava.class.pathの値になります。

CLASSPATH環境変数は、-classpath (または-cp)オプションと異なって扱われることはありません。 ワイルドカードは、これらのすべての場合で有効です。 ただし、Class-Path JARマニフェストのヘッダーでは、クラス・パスのワイルドカードが無効です。

クラス・パスとパッケージ名

Javaのクラスはパッケージとして編成され、各パッケージはファイル・システム内のディレクトリにマッピングされています。 ただし、ファイル・システムとは異なり、パッケージ名を指定するときは、パッケージ名の一部ではなく必ず全体を指定します。 たとえば、java.awt.Buttonのパッケージ名は、必ずjava.awtと指定されます。

たとえば、Java JREがutility.myappパッケージ内のCool.classという名前のクラスを探すように設定する場合を考えてみましょう。 そのディレクトリへのパスがC:\java\MyClasses\utility\myappであれば、C:\java\MyClassesを含むようにクラス・パスを設定します。 このアプリケーションを実行するには、次のjavaコマンドを使用します。

java -classpath C:\java\MyClasses utility.myapp.Cool

コマンドには完全なパッケージ名が指定されます。 たとえば、クラス・パスにC:\java\MyClasses\utilityが含まれるように設定したうえで、java myapp.Coolコマンドを使用することはできません。 そのクラスが見つからないためです。

なぜこのようなクラスのパッケージ名が認められないのか疑問に思うかもしれません。 それは、クラスのパッケージ名はそのクラスの一部であり、変更できないからです。パッケージ名を変更するには、クラスをコンパイルしなおさなければなりません。

パッケージ指定のメカニズムに関連した興味深い事例として、「同じパッケージに属する複数のクラス・ファイルが別々のディレクトリに存在する」という状況が可能です。 この場合、各クラスのパッケージ名は同じですが、それぞれのファイルへのパスは、クラス・パス内の別々のディレクトリで始まります。

java -classpath C:\java\MyClasses\myclasses.jar utility.myapp.Cool

java -classpath C:\java\MyClasses;C:\java\OtherClasses ...