名前
javac - Java宣言の読取りとクラス・ファイルへのコンパイル
シノプシス
javac
[options] [sourcefiles-or-classnames]
- options
- コマンド行オプション。
- sourcefiles-or-classnames
- (たとえば、
Shape.java
)のコンパイルの対象となるソース・ファイル、または注釈(たとえば、geometry.MyShape
)に対して処理する以前にコンパイルしたクラスの名前。
説明
javac
コマンドは、Javaプログラミング言語で記述されたモジュール宣言、パッケージ宣言および型宣言を含む「ソース・ファイル」を読み取り、Java Virtual Machineで実行される「クラス・ファイル」にコンパイルします。
javac
コマンドは、Javaソース・ファイルおよびクラス内の「プロセス注釈」も実行できます。
ソース・ファイルのファイル名拡張子は.java
である必要があります。 クラス・ファイルの名前拡張子は.class
です。 通常、ソース・ファイルとクラス・ファイルの両方には、コンテンツを識別するファイル名があります。 たとえば、Shape
というクラスはShape.java
というソース・ファイルで宣言され、Shape.class
というクラス・ファイルにコンパイルされます。
javac
にソース・ファイルを指定するには、次の2つの方法があります:
少数のソース・ファイルの場合、コマンドラインでファイル名をリストできます。
多数のソース・ファイルに対して、コマンドラインで
@
filenameオプションを使用して、ファイル名がリストされた「引数ファイル」を指定できます。javac
引数ファイルの詳細は、オプションおよび「コマンドライン引数ファイル」の詳細は、「標準オプション」を参照してください。
コマンド行または引数ファイルに指定されたソース・ファイルの順序は、重要ではありません。javac
は、グループとしてファイルをまとめてコンパイルし、各種ソース・ファイル内の宣言間の依存関係を自動的に解決します。
javac
では、「ソース・コードの契約」で説明されているように、ソース・ファイルはファイル・システム上の1つ以上のディレクトリ階層に配置されると想定しています。
ソース・ファイルをコンパイルするには、ソース・ファイルのコードで使用、拡張または実装されているすべてのクラスまたはインタフェースの宣言を、javac
で検索する必要があります。 これにより、javac
では、これらのクラスおよびインタフェースにアクセスする権限がコードにあることを確認できます。 これらのクラスおよびインタフェースのソース・ファイルを明示的に指定するかわりに、コマンド行オプションを使用して、ソース・ファイルの検索場所をjavac
に指定できます。 これらのソース・ファイルを以前にコンパイルしたことがある場合は、オプションを使用して、対応するクラス・ファイルの検索場所をjavac
に指示できます。 すべてのオプションの名前が"path"で終わるオプションについては、「標準オプション」で説明し、「コンパイルの構成」および「モジュール、パッケージおよびタイプの宣言の検索」でさらに説明します。
デフォルトでは、javac
は各ソース・ファイルをソース・ファイルと同じディレクトリのクラス・ファイルにコンパイルします。 ただし、-d
オプションで個別の宛先ディレクトリを指定することをお薦めします。
コマンドラインoptionsおよび「環境変数」では、javac
が次の様々なタスクを実行する方法も制御します:
- JDKの以前のリリースで実行されるコードをコンパイル。
- デバッガの下で実行するコードをコンパイル。
- Javaソース・コード内のスタイル上の問題をチェックしています。
javadoc
のコメント(/** ... */
)の問題をチェックしています。- ソース・ファイルおよびクラス・ファイルの注釈を処理します。
- コンパイル時環境でモジュールのアップグレードおよびパッチ適用を行います。
javac
では「プラットフォームの以前のリリースのコンパイル」がサポートされており、多くのAPIの1つを使用してJavaコードから起動することもできます
オプション
javac
では、標準以外の、または高度な使用を目的とした「標準オプション」および「追加オプション」が提供されます。
いくつかのオプションには1つ以上の引数があります。 引数に空白やその他の空白文字が含まれる場合、javacの起動に使用する環境の表記規則に従って値を引用符で囲む必要があります。 オプションが単一のダッシュ(-
)で始まる場合、引数はオプション名の直後か、オプションに応じてコロン(:
)または空白で区切る必要があります。 オプションが二重ダッシュ(--
)で始まっている場合、引数は空白または追加の空白を含まない(=
)文字と等価のいずれかで区切ることができます。 たとえば、
-Aname="J. Duke"
-proc:only
-d myDirectory
--module-version 3
--module-version=3
次のオプション・リストでは、pathの引数は、プラットフォーム・パス・セパレータ文字(Windowsでは;
をセミコロンで、他のシステムでは:
をコロンで囲みます。)で区切られたファイル・システム上のロケーションのリストで構成される検索パスを表します。 このオプションに応じて、ファイル・システムのロケーションは、ディレクトリ、JARファイルまたはJMODファイルになります。
標準オプション
@
filename- ファイルからオプションおよびファイル名を読み取ります。
javac
コマンドを短くしたり簡潔にしたりするために、javac
コマンド(-J
オプション以外)の引数を含む1つ以上のファイルを指定できます。 これにより、任意のオペレーティング・システムで任意の長さのjavac
コマンドを作成できます。 「コマンド行引数ファイル」を参照してください。 -A
key[=
value]- 注釈プロセッサに渡すオプションを指定します。 これらのオプションは、
javac
が直接解釈するのではなく、それぞれのプロセッサによって使用できるようにします。 key値は、ドット(.
)で区切られた1つ以上の識別子である必要があります。 --add-modules
module,
module- 初期モジュールに加えて解決するルート・モジュールを指定します。moduleが
ALL-MODULE-PATH
の場合は、モジュール・パス上のすべてのモジュールを指定します。 --boot-class-path
pathまたは-bootclasspath
pathブートストラップ・クラス・ファイルの位置をオーバーライドします。
ノート: これは、JDK 9より前のリリースでコンパイルする場合にのみ使用できます。 該当する場合、詳細は、
--release
、-source
または-target
の説明を参照してください。 JDK 9以上の場合は、--system
を参照してください。--class-path
path、-classpath
pathまたは-cp
pathユーザー・クラス・ファイルと注釈プロセッサを見つける場所を指定します。 このクラス・パスは
CLASSPATH
環境変数のユーザー・クラス・パスをオーバーライドします。--class-path
、-classpath
または-cp
が指定されていない場合、ユーザーのクラス・パスは、CLASSPATH
環境変数の値(設定されている場合)または現在のディレクトリになります。モジュールのコードをコンパイルしていない場合に、
--source-path
または -ourcepathオプションが指定されていないと、ソース・ファイルに対してユーザー・クラス・パスも検索されます。-processorpath
オプションが指定されない場合、注釈プロセッサのクラスパスも検索されます。
-d
directoryクラス・ファイルの宛先ディレクトリ(または「クラス出力ディレクトリ」)を設定します。 クラスがパッケージの一部である場合、
javac
はクラス・ファイルを(必要に応じて)およびパッケージ名を反映するサブディレクトリに置きます。 ディレクトリおよび必要なサブディレクトリは、まだ存在しない場合は作成されます。-d
オプションが指定されていない場合、javac
は各クラス・ファイルを生成元のソース・ファイルと同じディレクトリに配置します。複数のモジュールのコードをコンパイルする場合を除き、クラス出力ディレクトリの内容はパッケージ階層に編成されます。 複数のモジュールに対してコードをコンパイルする場合、出力ディレクトリの内容はモジュール階層に編成され、各モジュールの内容は個別のサブディレクトリに保持されます。それぞれパッケージ階層として編成されます。
ノート: 1つ以上のモジュールのコードをコンパイル中に、以前にコンパイルされたクラスを検索するときにクラス出力ディレクトリが自動的にチェックされます。 モジュールのコンパイルをしない場合には、下位互換性のために、以前にコンパイルしたクラスのディレクトリは自動的にチェックされないため、
--class-path
オプションまたはその代替形式のいずれかを使用して、ユーザー・クラス・パスのいずれかのロケーションとしてクラス出力ディレクトリを指定することをお薦めします。-deprecation
- 非推奨のメンバーやクラスの使用またはオーバーライドのたびに説明を表示します。
-deprecation
オプションが指定されていない場合、javac
は、非推奨のメンバーやクラスを使用またはオーバーライドしているソース・ファイルのサマリーを表示します。-deprecation
オプションは-Xlint:deprecation
の省略表記です。 --enable-preview
- プレビュー言語機能を有効にします。
-source
または--release
のいずれかと組み合せて使用します。 -encoding
encoding- EUC-JPやUTF-8など、ソース・ファイルで使用される文字エンコーディングを指定します。
-encoding
オプションが指定されていない場合は、プラットフォームのデフォルト・コンバータが使われます。 -endorseddirs
directories承認された標準パスの位置をオーバーライドします。
ノート: これは、JDK 9より前のリリースでコンパイルする場合にのみ使用できます。 該当する場合、詳細は、
--release
、-source
または-target
の説明を参照してください。-extdirs
directoriesインストールされている拡張のロケーションをオーバーライドします。
directories
は、プラットフォーム・パス・セパレータ(Windowsの;
およびそれ以外の:
)で区切られたディレクトリのリストです。 指定したディレクトリ内の各JARファイルから、クラス・ファイルが検索されます。 見つかったすべてのJARファイルがクラス・パスの一部になります。拡張メカニズムをサポートするプラットフォームのリリースに対してコンパイルを行う場合、このオプションは拡張クラスを含むディレクトリを指定します。 [プラットフォームの他のリリースのコンパイル]も参照してください。
ノート: これは、JDK 9より前のリリースでコンパイルする場合にのみ使用できます。 該当する場合、詳細は、
--release
、-source
または-target
の説明を参照してください。-g
- ローカル変数を含むすべてのデバッグ情報を生成します。 デフォルトでは、行番号およびソース・ファイル情報だけが生成されます。
-g:
[lines
,vars
,source
]コンマ区切りのキーワード・リストで指定された種類のデバッグ情報のみを生成します。 有効なキーワードは、次のとおりです。
lines
- 行番号のデバッグ情報。
vars
- ローカル変数のデバッグ情報。
source
- ソース・ファイルのデバッグ情報。
-g:none
- デバッグ情報を生成しません。
-h
directory生成されたネイティブ・ヘッダー・ファイルを配置する場所を指定します。
このオプションを指定すると、ネイティブ・メソッドを含むクラス、または
java.lang.annotation.Native
注釈の付いた1つ以上の定数を持つクラスごとに、ネイティブ・ヘッダー・ファイルが生成されます。 クラスがパッケージの一部である場合、コンパイラはネイティブのヘッダー・ファイルを、モジュール名(必要に応じて)およびパッケージ名を反映するサブディレクトリに置きます。 ディレクトリおよび必要なサブディレクトリは、まだ存在しない場合は作成されます。--help
、-help
または-?
- 標準オプションのシノプシスを表示します。
--help-extra
または-X
- その他の一連のオプションのシノプシスを出力します。
--help-lint
-Xlint
オプションでサポートされるキーを出力します。-implicit:
[none
,class
]暗黙的に参照されるファイルのクラス・ファイルを生成するかどうかを指定します:
-implicit:class
---クラス・ファイルを自動的に生成します。-implicit:none
---クラス・ファイルの生成を抑制します。
このオプションが指定されない場合、デフォルトでクラス・ファイルが自動的に生成されます。 この場合、注釈処理を行うときにクラス・ファイルが生成された場合、コンパイラは警告を発行します。
-implicit
オプションが明示的に設定されている場合、警告は発行されません。 「モジュール、パッケージおよびタイプの宣言の検索」を参照してください。-J
optionoptionをランタイム・システムに渡します。ここで、optionは、javaコマンドで説明されているJavaオプションのいずれかです。 たとえば、
-J-Xms48m
と指定すると、スタートアップ・メモリーは48Mバイトに設定されます。ノート:
CLASSPATH
環境変数、-classpath
オプション、-bootclasspath
オプションおよび-extdirs
オプションでは、javac
の実行に使用されるクラスは指定されません。 これらのオプションや変数でコンパイラ実装をカスタマイズしようとすることは危険であり、目的が実現されないことがあります。 コンパイラの実装をカスタマイズする必要がある場合は、-J
オプションを使用して、基礎となるJavaランチャにオプションを渡すことができます。--limit-modules
module,
module*- 観測可能なモジュールの世界を制限します。
--module
module-name (,
module-name) *または-m
module-name (,
module-name) *- 出力ディレクトリ内の対応するファイルより新しい名前の付いたモジュール内のソース・ファイルをコンパイルします。
--module-path
pathまたは-p
path- アプリケーション・モジュールの検索場所を指定します。
--module-source-path
module-source-path- 複数のモジュールでコードをコンパイルするときに、ソース・ファイルを検索する場所を指定します。 [コンパイル・モード]および「モジュール・ソース・パス・オプション」を参照してください。
--module-version
version- コンパイル中のモジュールのバージョンを指定します。
-nowarn
- 警告メッセージを無効にします。 このオプションは、
-Xlint:none
オプションと同じように動作します。 -parameters
- メソッドのパラメータに反映するためのメタデータを生成します。 Reflection APIのメソッド
java.lang.reflect.Executable.getParameters
が取得できるように、コンストラクタやメソッドの仮パラメータ名を、生成されたクラス・ファイルに格納します。 -proc:
[none
,only
,full
]- 注釈処理とコンパイルが実行されるかどうかを制御します。
-proc:none
は、注釈処理なしでコンパイルが実行されることを意味します。-proc:only
は、注釈処理のみが実行され、後続のコンパイルは実行されないことを意味します。 このオプションを使用しない場合、または-proc:full
を指定すると、注釈の処理とコンパイルが実行されます。 -processor
class1[,
class2,
class3...]- 実行する注釈プロセッサの名前。 これを指定した場合、デフォルトの検索処理は省略されます。
--processor-module-path
path- 注釈プロセッサを検索するために使用されるモジュール・パスを指定します。
--processor-path
pathまたは-processorpath
path- 注釈プロセッサを見つける場所を指定します。 このオプションが使用されていない場合、クラス・パスでプロセッサが検索されます。
-profile
profile使用されているAPIが指定されたプロファイルで使用可能かどうかをチェックします。
ノート: これは、JDK 9より前のリリースでコンパイルする場合にのみ使用できます。 該当する場合、詳細は、
--release
、-source
または-target
の説明を参照してください。--release
release指定されたJava SEリリースのJavaプログラミング言語のルールに従ってソース・コードをコンパイルし、リリースするターゲットとなるクラス・ファイルを生成します。 ソース・コードが、指定リリースの結合されたJava SEおよびJDK APIに対してコンパイルされます。
releaseでは、サポートされている値は、現在のJava SEリリース、およびコマンド行ヘルプで詳細に表示される限定された数の以前のリリースです。
現行リリースの場合、Java SE APIは、リリースのJava SEモジュールによってエクスポートされる
java.*
、javax.*
およびorg.*
パッケージで構成されます。JDK APIは、リリースのJDKモジュールにエクスポートされるcom.*
およびjdk.*
パッケージと、標準ではエクスポートされるが、Java SE以外のモジュールではエクスポートされるjavax.*
パッケージで構成されます。以前のリリースの場合、Java SE APIおよびJDK APIはそのリリースで定義されています。
ノート:
--release
を使用する場合、--source
/-source
、--target
/-target
オプションも使用できません。ノート:
--release
を使用してJava Platform Module Systemをサポートするリリースを指定する場合、--add-exports
オプションを使用して、指定リリースのJava SE、JDKおよび標準モジュールでエクスポートされるパッケージのセットを拡張することはできません。-s
directory生成されたソース・ファイルの配置に使用されるディレクトリを指定します。 クラスがパッケージの一部である場合、コンパイラはソース・ファイルを、モジュール名(必要に応じて)およびパッケージ名を反映するサブディレクトリに置きます。 ディレクトリおよび必要なサブディレクトリは、まだ存在しない場合は作成されます。
複数のモジュールのコードをコンパイルする場合を除き、ソース出力ディレクトリの内容はパッケージ階層に整理されます。 複数のモジュールのコードをコンパイルする場合、ソース出力ディレクトリのコンテンツは、モジュール階層に編成されます。各モジュールのコンテンツは、個別のサブディレクトリに編成され、それぞれパッケージ階層として編成されます。
--source
releaseまたは-source
release指定されたJava SEリリースのJavaプログラミング言語の規則に従ってソース・コードをコンパイルします。 releaseでは、サポートされている値は、現在のJava SEリリース、およびコマンド行ヘルプで詳細に表示される限定された数の以前のリリースです。
このオプションを指定しない場合は、デフォルトで、現在のJava SEリリースのJavaプログラミング言語のルールに従ってソース・コードがコンパイルされます。
--source-path
pathまたは-sourcepath
pathソース・ファイルの検索場所を指定します。 複数のモジュールをまとめてコンパイルする場合を除き、これはクラスまたはインタフェース定義の検索に使用されるソース・コード・パスです。
ノート: クラス・パスを通じて見つかったクラスは、それらのソース・ファイルも見つかった場合にコンパイルできます。 「モジュール、パッケージおよびタイプの宣言の検索」を参照してください。
--system
jdk |none
- システム・モジュールのロケーションを上書きします。
--target
releaseまたは-target
release指定したJava SEリリースに適した
class
ファイルを生成します。 releaseでは、サポートされている値は、現在のJava SEリリース、およびコマンド行ヘルプで詳細に表示される限定された数の以前のリリースです。ノート: ターゲット・リリースはソース・リリース以上である必要があります。 (
--source
を参照してください。)--upgrade-module-path
path- アップグレード可能なモジュールのロケーションを上書きします。
-verbose
- コンパイラが何をしているのかに関するメッセージを出力します。 メッセージには、ロードされた各クラスおよびコンパイルされた各ソース・ファイルに関する情報が含まれます。
--version
または-version
- バージョン情報を出力します。
-Werror
- 警告が発生したらコンパイルを終了します。
追加オプション
--add-exports
module/
package=
other-module(,
other-module)*- other-moduleの値が
ALL-UNNAMED
の場合、その定義モジュールから追加モジュールまたはすべての名前なしモジュールにエクスポートされるパッケージを指定します。 --add-reads
module=
other-module(,
other-module)*- 特定のモジュールが必要とする追加のモジュールを指定します。
--default-module-for-created-files
module-name- 何も指定されていないか無効な場合に注釈プロセッサによって作成されるファイルのフォールバック・ターゲット・モジュールを指定します。
-Djava.endorsed.dirs=
dirs承認された標準パスの位置をオーバーライドします。
ノート: これは、JDK 9より前のリリースでコンパイルする場合にのみ使用できます。 該当する場合、詳細は、
--release
、-source
または-target
の説明を参照してください。-Djava.ext.dirs=
dirsインストールされた拡張機能の位置をオーバーライドします。
ノート: これは、JDK 9より前のリリースでコンパイルする場合にのみ使用できます。 該当する場合、詳細は、
--release
、-source
または-target
の説明を参照してください。--patch-module
module=
path- JARファイルまたはディレクトリ内のクラスおよびリソースでモジュールをオーバーライドまたは拡張します。
-Xbootclasspath:
pathブートストラップ・クラス・ファイルの位置をオーバーライドします。
ノート: これは、JDK 9より前のリリースでコンパイルする場合にのみ使用できます。 該当する場合、詳細は、
--release
、-source
または-target
の説明を参照してください。-Xbootclasspath/a:
pathブートストラップ・クラス・パスに接尾辞を追加します。
ノート: これは、JDK 9より前のリリースでコンパイルする場合にのみ使用できます。 該当する場合、詳細は、
--release
、-source
または-target
の説明を参照してください。-Xbootclasspath/p:
pathブートストラップ・クラス・パスに接頭辞を追加します。
ノート: これは、JDK 9より前のリリースでコンパイルする場合にのみ使用できます。 該当する場合、詳細は、
--release
、-source
または-target
の説明を参照してください。-Xdiags:
[compact
,verbose
]- 診断モードを選択します。
-Xdoclint
javadoc
コメント内の問題の推奨チェックを有効にします-Xdoclint:
(all
|none
|[-
]group)[/
access]特定のグループのチェックを有効または無効にします。
groupには、次のいずれかの値を指定できます:
accessibility
html
missing
reference
syntax
変数accessは、
-Xdoclint
オプションによってチェックされるクラスおよびメンバーの最小可視性レベルを指定します。 これは、次の値のいずれかにできます(可視性が最大から最小の順序で示しています)。public
protected
package
private
デフォルトのaccessレベルは
private
です。これらのチェック・グループの詳細は、
javadoc
コマンドの-Xdoclint
オプションを参照してください。javac
コマンドで-Xdoclint
オプションはデフォルトで無効にされています。たとえば、次のオプションは、protected以上のアクセス・レベル(protectedおよびpublicを含む)を持つクラスおよびメンバー(すべてのチェックのグループで)をチェックします。
-Xdoclint:all/protected
次のオプションは、アクセス・レベルがpackage以上の(これには、パッケージ、保護およびパブリックが含まれます)であるクラスおよびメンバーのHTMLエラーをチェックしないことを除いて、すべてのアクセス・レベルのすべてのグループのチェックを有効にします:
-Xdoclint:all,-html/package
-Xdoclint/package:
[-
]packages(,
[-
]package)*- 特定のパッケージのチェックを有効または無効にします。 各packageは、パッケージの修飾名、またはパッケージ名のプレフィクスの後に
.*
が続きます。このプレフィクスは、指定されたパッケージのすべてのサブパッケージに展開されます。 各packageの前にハイフン(-
)を付けて、指定したパッケージに対するチェックを無効にできます。 -Xlint
- 推奨されるすべての警告を有効にします。 このリリースでは、利用可能なすべての警告を有効にすることが推奨されています。
-Xlint:
[-
]key(,
[-
]key)*有効または無効にする警告をカンマで区切って指定します。 指定した警告を無効にするには、キーの前にハイフン(
-
)を付けます。keyでサポートされている値は次のとおりです:
all
: すべての警告を有効にします。auxiliaryclass
: ソース・ファイルで非表示になり、他のファイルで使用されている補助クラスについて警告します。cast
: 不要なキャストの使用について警告します。classfile
: クラス・ファイルの内容に関連する問題を警告します。deprecation
: 非推奨アイテムの使用について警告します。dep-ann
:@Deprecated
注釈を使用せずに、javadoc
で非推奨としてマークされたアイテムについて警告します。divzero
: 定数整数0で除算について警告します。empty
:if
の後に空の文について警告します。exports
: モジュールのエクスポートに関する問題を警告します。fallthrough
: switch文の1つのケースから次のケースへの落下について警告します。finally
: 通常終了しないfinally
句について警告します。module
: モジュール・システム関連の問題について警告します。opens
: モジュール・オープンに関連する問題について警告します。options
: コマンドライン・オプションの使用に関する問題を警告します。overloads
: メソッドのオーバーロードに関連する問題を警告します。overrides
: メソッドのオーバーライドに関連する問題について警告します。path
: コマンドl ineの無効なパス要素について警告します。processing
: 注釈処理に関連する問題について警告します。rawtypes
: RAWタイプの使用について警告します。removal
: 削除対象としてマークされたAPIの使用について警告します。requires-automatic
: requires句での自動モジュールの使用について、開発者に警告します。requires-transitive-automatic
: 自動モジュールが推移的であることを警告します。serial
: シリアル・バージョンIDを指定しない直列化可能クラスについて警告します。 また、直列化可能要素からpublic以外のメンバーへのアクセスについて警告します。static
: インスタンスを使用した静的メンバーへのアクセスについて警告します。try
: tryブロック(that is, try-with-resources)の使用に関する問題を警告します。unchecked
: 未チェックの操作について警告します。varargs
: 安全でない可能性のあるvararg
メソッドについて警告します。none
: すべての警告を無効にします。
「 -Xlintキーの使用例」を参照してください。
-Xmaxerrs
number- 印刷するエラーの最大数を設定します。
-Xmaxwarns
number- 印刷する警告の最大数を設定します。
-Xpkginfo:
[always
,legacy
,nonempty
]次のいずれかのオプションを使用して、
javac
コマンドがpackage-info.java
ファイルからpackage-info.class
ファイルをいつどのように生成するかを指定します:always
package-info.java
ファイルごとにpackage-info.class
ファイルを生成します。 このオプションは、各.java
ファイルに対応する.class
ファイルがあることをチェックするAntなどのビルド・システムを使用する場合に役立つことがあります。legacy
package-info.java
に注釈が含まれている場合にのみ、package-info.class
ファイルを生成します。package-info.java
にコメントのみが含まれる場合、このオプションではpackage-info.class
ファイルは生成されません。ノート:
package-info.java
ファイルのすべての注釈にRetentionPolicy.SOURCE
が含まれている場合、package-info.class
ファイルは生成されるが空になることがあります。nonempty
package-info.class
ファイルが生成されるのは、package-info.java
にRetentionPolicy.CLASS
またはRetentionPolicy.RUNTIME
の注釈が含まれている場合のみです。
-Xplugin:
name args- 実行されるプラグインの名前およびオプションの引数を指定します。 argsが指定されている場合、nameとargsは引用符で囲むか、それ以外の場合は名前とすべての引数の間にある空白文字をエスケープする必要があります。 プラグインのAPIの詳細は、jdk.compiler/com.sun.source.util.Plugin APIドキュメントを参照してください。
-Xprefer:
[source
,newer
]次のオプションのいずれかを使用して、暗黙的にコンパイルされるクラスについて、てソース・ファイルとクラス・ファイルの両方が見つかった場合、どのファイルを読み取るかを指定します。 「モジュール、パッケージおよびタイプの宣言の検索」を参照してください。
-Xprefer:newer
: (default)型のソース・ファイルまたはクラス・ファイルの新しいファイルを読み取ります。-Xprefer:source
: ソース・ファイルを読み取ります。-Xprefer:source
は、SOURCE
の保持ポリシーで宣言された注釈に注釈プロセッサがアクセスできることを確認する場合に使用します。
-Xprint
- 指定された型のテキスト表現をデバッグ目的で出力します。 これは、注釈処理やコンパイルを行いません。 出力形式は変更される可能性があります。
-XprintProcessorInfo
- ある特定のプロセッサが処理を依頼されている注釈に関する情報を出力します。
-XprintRounds
- 初回および後続の注釈処理のラウンドに関する情報を出力します。
-Xstdout
filename- コンパイラのメッセージを、指定されたファイルに送ります。 デフォルトでは、コンパイラのメッセージは
System.err
に送られます。
環境変数
CLASSPATH
--class-path
オプションまたはその代替フォームが指定されていない場合、クラス・パスはデフォルトでCLASSPATH
環境変数の値になります(設定されている場合)。 ただし、この環境変数の設定は避けてください。--class-path
オプションを使用してクラス・パスの明示的な値(必要な場合)を指定してください。
JDK_JAVAC_OPTIONS
JDK_JAVAC_OPTIONS
環境変数のコンテンツは、ホワイト・スペース()またはホワイト・スペース文字(\n
, \t
, \r
または\f
)で区切られ、引数のリストとしてjavac
に渡されるコマンドライン引数の前に付加されます。
環境変数に対するエンコーディング要件は、システム上のjavac
コマンドラインと同じです。 JDK_JAVAC_OPTIONS
環境変数コンテンツは、コマンドラインで指定されたものと同じ方法で処理されます。
一重引用符('
)または二重引用符("
)を使用すると、空白文字を含む引数を囲むことができます。 開始引用符と対応する最初の終了引用符の間の内容すべてが引用符のペアを除いて保存されます。 一致する引用符が見つからない場合、ランチャはエラー・メッセージで中断します。@
filesは、コマンド行で指定されているためサポートされています。 ただし、@
filesと同様に、ワイルドカードの使用はサポートされていません。
空白が含まれる引数を引用符で囲む例:
export JDK_JAVAC_OPTIONS='@"C:\white spaces\argfile"'
export JDK_JAVAC_OPTIONS='"@C:\white spaces\argfile"'
export JDK_JAVAC_OPTIONS='@C:"white spaces"\argfile'
コマンド行引数ファイル
引数ファイルにはコマンド行オプションとソース・ファイル名を任意に組み合せて含めることができます。 ファイル内の引数は、空白文字または改行文字で区切ることができます。 ファイル名に空白が含まれている場合は、そのファイル名全体を二重引用符で囲みます。
引数ファイル内のファイル名は、現在のディレクトリから相対的で、引数ファイルの場所に対してではありません。 これらのリスト(例: *.java
の指定)では、ワイルドカード(*
)は使用できません。 ファイルを再帰的に解釈するためのアットマーク(@
)の使用はサポートされていません。 -J
オプションは、引数ファイルをサポートしないランチャに渡されるためサポートされていません。
javac
コマンドを実行する場合は、各引数ファイルのパスと名前を、先頭に(@
)文字を付けて渡します。 javac
コマンドは、アットマーク (@
)で始まる引数を検出すると、そのファイルの内容を引数リストに展開します。
javac @filenameの使用例
- 単一の引数ファイル
すべての
javac
引数を保持するargfile
という名前の単一の引数ファイルを使用できます。javac @argfile
この引数ファイルには、次の2つの引数ファイルの例で示されている両方のファイルの内容を含めることができます。
- 2つの引数ファイル
たとえば、
javac
オプション用に1ファイル、ソース・ファイル名用に1ファイルというように、2つの引数ファイルを作成できます。 次のリストでは、行の継続文字を使用していないことに注意してください。次のファイルを含む
options
という名前のファイルを作成します:LinuxおよびmacOS:
-d classes -g -sourcepath /java/pubs/ws/1.3/src/share/classes
Windows:
-d classes -g -sourcepath C:\java\pubs\ws\1.3\src\share\classes
次のファイルを含む
classes
という名前のファイルを作成します:MyClass1.java MyClass2.java MyClass3.java
次に、次のように
javac
コマンドを実行します。javac @options @classes
- パスを使用した引数ファイル
引数ファイルにはパスを指定できますが、ファイル内のすべてのファイル名は、現在の作業ディレクトリに相対的になります(
path1
やpath2
でなく)。javac @path1/options @path2/classes
ソース・コードの契約
Java言語では、クラスおよびインタフェースをパッケージに編成できます。パッケージは、モジュールに編成できます。javac
では、ファイルシステムのディレクトリ内のソース・ファイルの物理的な配置によってクラスがパッケージに反映され、パッケージがモジュールにもミラー化されると想定しています。
モジュール名とパッケージ名は小文字で始まり、そのクラス名は大文字で始まります。
パッケージのソース・コードの配置
クラスとインタフェースをパッケージに編成すると、そのパッケージはディレクトリとして表され、すべてのサブパッケージはサブディレクトリとして表されます。
たとえば:
パッケージ
p
は、p
と呼ばれるディレクトリとして表現されます。パッケージ
p.q
-- つまり、パッケージp
のサブパッケージq
-- 、ディレクトリp
のサブディレクトリq
として表されます。 したがって、p.q
パッケージを表すディレクトリ・ツリーは、Windowsではp\q
であり、他のシステムではp/q
です。パッケージの
p.q.r
は、ディレクトリ・ツリーp\q\r
(Windows上で)またはp/q/r
(他のシステム)として表されます。
ディレクトリまたはサブディレクトリ内では、.java
ファイルは対応するパッケージまたはサブパッケージ内のクラスおよびインタフェースを表します。
たとえば:
パッケージ
p
で宣言されたクラスX
は、p
ディレクトリ内のファイルX.java
で表されます。パッケージ
p.q
で宣言されたクラスY
は、p
ディレクトリのq
サブディレクトリにあるファイルY.java
で表されます。パッケージ
p.q.r
で宣言されたクラスZ
は、p\q
(Windows上で)またはp/q
(他のシステム)のサブディレクトリr
のファイルZ.java
により表されます。
状況によっては、前述のように構造化された個別のディレクトリ、およびjavac
に指定されたディレクトリの集約リストにコードを分割すると便利です。
モジュールのソース・コードの配置
Java言語では、モジュールとは再利用を目的として設計されたパッケージの集合のことです。 クラスやインタフェースの.java
ファイルに加え、各モジュールにはmodule-info.java
と呼ばれるソース・ファイルがあります。このソース・ファイルは次のとおりです:
モジュール名を宣言
には、モジュール(他のモジュールで再利用できるようにします)によってエクスポートされたパッケージがリストされます。
モジュール(エクスポートしたパッケージを再利用)で必要なその他のモジュールを一覧表示します。
パッケージがモジュールに編成されると、モジュールは、モジュール内のパッケージを表す1つ以上のディレクトリによって表され、その中にmodule-info.java
ファイルが含まれます。 モジュール名と同じ名前の単一のディレクトリをモジュール(例:前述の「パッケージ階層」)のパッケージを表すディレクトリ・ツリーとともにmodule-info.java
ファイルを格納するために、これは便利ですが、必須ではありません。 モジュールのソース・コードの正確な配置は、通常、開発環境(IDE)またはビルド・システムに採用される規則によって決定されます。
たとえば:
モジュール
a.b.c
は、すべてのシステムのディレクトリa.b.c
で表すことができます。モジュール宣言は、
a.b.c
ディレクトリのファイルmodule-info.java
によって表現されます。モジュールに
p.q.r
パッケージが含まれる場合、a.b.c
ディレクトリにはディレクトリ・ツリーp\q\r
(Windows上で)またはp/q/r
(他のシステム)が含まれます。
開発環境では、モジュールに指定されたディレクトリとjavac
によって読み取られるソース・ファイルの間に、いくつかのディレクトリ階層が規定される場合があります。
たとえば:
モジュール
a.b.c
は、ディレクトリa.b.c
で表すことができます。モジュール宣言およびモジュール・パッケージは、
src\main\java
(Windows上で)やsrc/main/java
(他のシステム)などのa.b.c
の一部のサブディレクトリに含まれている可能性があります。
コンパイルの構成
この項では、基本的なコンパイルを実行するようにjavac
を構成する方法について説明します。
モジュールをサポートするリリースのプラットフォーム用にコンパイルする場合の詳細は、「モジュール・システムの構成」を参照してください。
ソース・ファイル
- コマンドラインでコンパイルするソース・ファイルを指定してください。
コンパイル・エラーがない場合、対応するクラス・ファイルは「出力ディレクトリ」内に配置されます。
システムによっては、コマンドラインに入力できる容量が制限される場合があります。これらの制限を回避するには、「引数ファイル」を使用できます。
モジュールのコードをコンパイルするときは、--module
または-m
オプションを使用して、ソース・ファイルを間接的に指定することもできます。
出力ディレクトリ
-d
オプションを使用して、コンパイル済クラス・ファイルを格納する出力ディレクトリを指定します。
これは通常、複数のモジュールからソース・コードをコンパイルしていないかぎり、「パッケージ階層」内に編成されます。その場合、「モジュール階層」として編成されます。
コンパイルが完了している場合に、1つ以上のモジュールをコンパイルすると、Java 「ランチャ」のモジュール・パスに出力ディレクトリを配置できます。格納できない場合は、Javaランチャのクラス・パスに出力ディレクトリを配置できます。
プリコンパイル済コード
コンパイルするコードがプラットフォームで提供される以上のライブラリを参照している場合があります。 その場合は、これらのライブラリをクラスパスまたはモジュール・パスに配置する必要があります。 ライブラリ・コードがモジュールにない場合は、クラスパスに配置し、モジュールにある場合はモジュール・パスに配置します。
--class-path
オプションを使用して、クラスパスに配置するライブラリを指定します。 クラス・パス上のロケーションは、「パッケージ階層」で編成する必要があります。 オプションの代替フォームを使用することもできます:-classpath
または-cp
。--module-path
オプションを使用して、モジュール・パスに配置するライブラリを指定します。 モジュール・パス上のロケーションは、モジュールまたはモジュールのディレクトリである必要があります。 オプションの代替フォームを使用することもできます:-p
。ライブラリ・モジュールのデフォルト構成の変更方法の詳細は、「モジュール・システムの構成」を参照してください。
ノート: クラス・パスおよびモジュール・パスのオプションは相互に排他的ではありませんが、1つ以上のモジュールのコードをコンパイルするときにクラス・パスを指定することは一般的ではありません。
追加ソース・ファイル
コンパイルするコードは、コマンドラインで指定されていない追加のソース・ファイル内のタイプを参照している可能性があります。 その場合は、ソース・パスまたはモジュール・パスのいずれかにソース・ファイルを置く必要があります。 次のオプションのうち1つだけを指定できます: モジュールのコードをコンパイルしていない場合、または1つのモジュールのコードのみをコンパイルしている場合はソース・パスを使用します。複数のモジュールのコードをコンパイルしている場合は、モジュール・ソース・パスを使用します。
--source-path
オプションを使用して、javacが読み取ることができる追加ソース・ファイルのロケーションを指定します。 ソース・パス上のロケーションは、「パッケージ階層」内に編成する必要があります。 オプションの代替フォームを使用することもできます:-sourcepath
。--module-source-path
オプションを1回以上使用して、javacによって読み込まれる可能性のある様々なモジュールの追加ソース・ファイルのロケーションを指定したり、複数のモジュールでソース・ファイルをコンパイルする場合に使用します。 各モジュール「個別」のロケーションを指定するか、すべての「同時に」のロケーションを指定できるようにソース・ファイルを編成できます。 詳細は、「モジュール・ソース・パス・オプション」を参照してください。
追加のソース・ファイル内のタイプを参照できるようにし、それらをコンパイルできないようにするには、-implicit
オプションを使用します。
ノート: 複数のモジュールに対してコードをコンパイルする場合は、常にモジュールのソース・パスを指定し、コマンドラインで指定されるすべてのソース・ファイルがモジュールのソース・パス上のいずれかのディレクトリに存在するか、またはそのサブディレクトリに存在する必要があります。
複数のソース・ファイルをコンパイルする例
この例では、greetings
パッケージ内のAloha.java
、GutenTag.java
、Hello.java
およびHi.java
ソース・ファイルをコンパイルします。
LinuxおよびmacOS:
% javac greetings/*.java
% ls greetings
Aloha.class GutenTag.class Hello.class Hi.class
Aloha.java GutenTag.java Hello.java Hi.java
Windows:
C:\>javac greetings\*.java
C:\>dir greetings
Aloha.class GutenTag.class Hello.class Hi.class
Aloha.java GutenTag.java Hello.java Hi.java
ユーザー・クラス・パスの指定例
前の例のいずれかのソース・ファイルの変更後、それを再コンパイルします。
LinuxおよびmacOS:
pwd
/examples
javac greetings/Hi.java
Windows:
C:\>cd
\examples
C:\>javac greetings\Hi.java
greetings.Hi
は、greetings
パッケージ内の他のクラスを参照しているため、コンパイラはこれらのその他のクラスを探す必要があります。 前の例は、デフォルトのユーザー・クラス・パスが、パッケージ・ディレクトリを含むディレクトリであるため機能します。 現在のディレクトリに関係なく、このファイルを再コンパイルする場合、CLASSPATH
を設定して、例のディレクトリをユーザー・クラス・パスに追加します。 この例では-classpath
オプションを使用します。
LinuxおよびmacOS:
javac -classpath /examples /examples/greetings/Hi.java
Windows:
C:\>javac -classpath \examples \examples\greetings\Hi.java
greetings.Hi
を変更してバナー・ユーティリティを使用するようにした場合、このユーティリティもユーザー・クラス・パスを通じてアクセスできる必要があります。
LinuxおよびmacOS:
javac -classpath /examples:/lib/Banners.jar \
/examples/greetings/Hi.java
Windows:
C:\>javac -classpath \examples;\lib\Banners.jar ^
\examples\greetings\Hi.java
greetings
パッケージのクラスを実行するには、プログラムがgreetings
パッケージおよびgreetings
クラスが使用するクラスにアクセスする必要があります。
LinuxおよびmacOS:
java -classpath /examples:/lib/Banners.jar greetings.Hi
Windows:
C:\>java -classpath \examples;\lib\Banners.jar greetings.Hi
モジュール・システムの構成
コンパイルに追加のモジュールを含める場合は、--add-modules
オプションを使用します。 これは、モジュール内にないコードをコンパイルする場合、または自動モジュール内にあり、コードが追加モジュール内のAPIを参照している場合に必要になることがあります。
コンパイルでモジュールのセットを制限する場合は、--limit-modules
オプションを使用します。 これは、コンパイル中のコードが、インストールされている限られたモジュールのセットを使用してシステムで実行可能であることを確認する場合に役立つことがあります。
カプセル化を解除し、追加パッケージをモジュールからのエクスポートとみなすように指定する場合は、--add-exports
オプションを使用します。 これは、ホワイト・ボックスのテストを実行する際に役立つことがあります。本番コードの内部APIへのアクセスに依存することは、お薦めしません。
モジュールで必要に応じて追加パッケージを考慮するように指定する場合は、--add-reads
オプションを使用します。 これは、ホワイト・ボックスのテストを実行する際に役立つことがあります。本番コードの内部APIへのアクセスに依存することは、お薦めしません。
--patch-module
オプションを使用して、任意のモジュールに追加コンテンツにパッチを適用できます。 詳細は、[モジュールのパッチ適用]を参照してください。
モジュール、パッケージおよびタイプの宣言の検索
ソース・ファイルをコンパイルするには、コンパイラがモジュールまたはタイプに関する情報を必要とすることがありますが、宣言がコマンドラインで指定されたソース・ファイルにありません。
javac
では、ソース・ファイルで使用、拡張または実装されるすべてのクラスまたはインタフェースの型情報が必要です。 これには、ソース・ファイルで明示的には言及されていなくても、継承を通じて情報を提供するクラスとインタフェースも含まれます。
たとえば、java.awt.Window
のサブクラスを作成する場合は、Window
の祖先クラスも使用しています: java.awt.Container
、java.awt.Component
およびjava.lang.Object
。
モジュールのコードをコンパイルする場合は、コンパイラがそのモジュールの宣言を使用可能にしている必要もあります。
成功した検索では、クラス・ファイルまたはソース・ファイル、あるいはその両方が生成される場合があります。 どちらも見つかった場合は、-Xprefer
オプションを使用して、使用するコンパイラに指示できます。
検索でソース・ファイルが検出されて使用されると、デフォルトで、javac
によりそのソース・ファイルがコンパイルされます。 この動作は、-implicit
で変更できます。
コンパイラは、注釈処理の完了後に、ある型情報の必要性を認識しない場合があります。 型情報がソース・ファイル内にあり、-implicit
オプションが指定されていない場合、コンパイラは、注釈処理を受けずにファイルがコンパイルされるという警告を表示します。 警告を無効にするには、コマンドライン(注釈処理の対象となる)でファイルを指定するか、-implicit
オプションを使用してそのようなソース・ファイルに対してクラス・ファイルを生成するかどうかを指定します。
javac
がこれらのタイプの宣言を特定する方法は、参照がモジュールのコード内に存在するかどうかによって異なります。
パッケージ指向パスの検索
パッケージ指向のロケーションで構成されるパスでソースまたはクラス・ファイルを検索するとき、javac
は、パス上の各ロケーションでファイルが存在する可能性があるかどうかをチェックします。 特定のファイルのシャドウの最初の発生(hides)で、同様の名前のファイルがその後に出現すること。 このシャドウは、別の名前のファイルの検索には影響しません。 これは、ソース・ファイルを検索する場合に便利です。ソース・ファイルは、共有コード、プラットフォーム固有コード、生成済コードなど、様々なロケーションにグループ化できます。 また、クラス・ファイルの代替バージョンをパッケージに注入し、デバッグまたは他のインストゥルメンテーションの理由に役立てる場合にも役立ちます。 ただし、互換性のないライブラリをクラスパスに追加する場合などにも、ライブラリは危険です。
モジュールの指向パスの検索
パッケージ宣言またはタイプ宣言のモジュール・パスをスキャンする前に、javac
は次のパスとロケーションを遅延スキャンして、コンパイルで使用するモジュールを判断します。
- モジュール・ソース・パス(
--module-source-path
オプションを参照) - アップグレード可能モジュール(
--upgrade-module-path
オプションを参照)のパス - システム・モジュール(
--system
オプションを参照) - ユーザー・モジュール・パス(
--module-path
オプションを参照)
どのモジュールについても、スキャン中に最初に発生したモジュールのシャドウは(hides)で、同様の名前のモジュールのその後の外観です。 モジュールの検索中、javac
は、モジュールによってエクスポートされたパッケージを判別し、各モジュールにモジュールのコンテンツへのパッケージ指向パスを関連付けることができます。 以前にコンパイルされたモジュールの場合、このパスは通常、ディレクトリまたは内部ディレクトリに類似した階層(JARファイルなど)を提供するファイルのいずれかの単一エントリになります。 したがって、モジュールによってエクスポートされることがわかっているパッケージ内の型を検索する場合、javac
ではその宣言を直接効率的に検索できます。
モジュールの宣言の検索
モジュールが以前にコンパイルされている場合、モジュール宣言は、モジュールのコンテンツのためのパッケージ階層のルートにあるmodule-info.class
という名前のファイルにあります。
モジュールが現在コンパイル中のモジュールの1つである場合、モジュール宣言は、クラス出力ディレクトリ内のモジュールのパッケージ階層のルートにあるmodule-info.class
という名前のファイルか、ソース・パス上のいずれかのロケーションにあるmodule-info.java
という名前のファイルか、またはモジュールのモジュール・ソース・パスの1つになります。
参照がモジュールにない場合のタイプの宣言の検索
モジュール内にないコードで参照されるタイプを検索すると、javac
は次の場所を参照します:
プラットフォーム・クラス(または、エクスポートされたプラットフォーム・モジュールのタイプ) (これは、コンパイル済クラス・ファイルの場合のみです。)
モジュール・パス上のモジュールのエクスポートされたパッケージ内に必要なタイプ(存在する場合)。 (これは、コンパイル済クラス・ファイルの場合のみです。)
クラスパスまたはソース・パス(あるいはその両方)のパッケージ内の型を指定します:
両方が指定されている場合、
javac
は、クラスパス上のコンパイル済クラス・ファイルおよびソース・パス上のソース・ファイルを検索します。クラスパスが指定されているがソース・パスではない場合、
javac
はコンパイルされたクラス・ファイルとソース・ファイルの両方をクラスパス上で検索します。クラスパスが指定されていない場合は、現在のディレクトリがデフォルトで使用されます。
クラスパスまたはソース・パス(あるいはその両方)でタイプを検索する際に、コンパイルされたクラス・ファイルとソース・ファイルの両方が見つかった場合は、最後に変更されたファイルがデフォルトで使用されます。 新しいソース・ファイルはコンパイルされ、以前にコンパイルされたファイルのバージョンをオーバーライドする場合があります。 デフォルトの動作は、-Xprefer
オプションを使用してオーバーライドできます。
参照がモジュール内にある場合のタイプの宣言の検索
モジュール内のコードで参照される型を検索する場合、javac
は、包含するモジュールの宣言を調べて、包含するモジュールが参照可能な別のモジュールからエクスポートされた型がパッケージ内にあるかどうかを判断します。 その場合、javac
はそのモジュールの定義を単純かつ直接的に見つけて、必要なタイプの定義を見つけます。 モジュールがコンパイル中のモジュールのもう1つでないかぎり、javac
はコンパイル済クラス・ファイルのみを検索します。 つまり、javac
では、プラットフォーム・モジュールのソース・ファイルやモジュール・パスのモジュールは検索されません。
参照される型が他の判読可能なモジュール内にない場合、javac
はコンパイル中のモジュールを調べて、型の宣言を見つけます。javac
では、次のように型の宣言が検索されます:
コマンド行、ソース・パスまたはモジュール・ソース・パスで指定されたソース・ファイル。
以前に出力ディレクトリにコンパイルされたファイル。
ディレクトリ階層
javac
では、一般的に、ソース・ファイルとコンパイル済クラス・ファイルは、ファイル・システムのディレクトリ階層、またはJARファイルなどの内部ディレクトリ階層でサポートされるファイル・タイプに整理されると想定しています。 3種類の異なる階層がサポートされています: 「パッケージ階層」、「モジュール階層」および「モジュール・ソース階層」。
javac
はソース・コードの編成に関してかなり緩和されていますが、ソースがある階層またはパッケージ階層に編成されることを期待した範囲を超えており、一般に開発環境およびビルド・ツールによって規定される組織に対応できます。一般的に、javac
およびJavaランチャは、コンパイルされたクラス・ファイルの編成に関してより厳しく、必要に応じてパッケージ階層またはモジュール階層に編成されます。
これらの階層のロケーションは、コマンド行オプション付きでjavac
に指定されます。コマンド行オプションの名前は、通常、--source-path
や--class-path
などの"path"で終わります。 また、一般的なルールとして、名前に--module-path
などのmodule
という語が含まれるパス・オプションは、モジュール階層を指定するために使用されます。ただし、一部のモジュール関連のパス・オプションでは、パッケージ階層をモジュール単位で指定できます。 他のすべてのパス・オプションは、パッケージ階層の指定に使用します。
パッケージ階層
パッケージ階層では、ディレクトリおよびサブディレクトリを使用してパッケージ名のコンポーネント部分を表し、ソース・ファイルまたはコンパイルされたクラス・ファイルを拡張子が.java
または.class
のファイルとして最もネストされたディレクトリに格納されているタイプで表現します。
たとえば、パッケージ階層では、クラスcom.example.MyClass
のソース・ファイルはcom/example/MyClass.javaファイルに格納されます。
モジュール階層
モジュール階層では、最初のレベルのディレクトリは階層内のモジュールに対して名前が付けられ、それらの各ディレクトリ内では、モジュールのコンテンツがパッケージ階層に編成されます。
たとえば、モジュール階層では、my.library
と呼ばれるモジュール内のcom.example.MyClass
という型のコンパイル済クラス・ファイルは、my.library/com/example/MyClass.class内に格納されます。
javac
(クラス出力ディレクトリ、ソース出力ディレクトリおよびネイティブ・ヘッダー出力ディレクトリ)で使用される様々な出力ディレクトリは、複数のモジュールがコンパイルされる際に、すべてモジュール階層に編成されます。
モジュール・ソース階層
個々のモジュールのソースは常にパッケージ階層に編成する必要がありますが、これらの階層をモジュールのソース階層にグループ化すると便利な場合があります。 これはモジュール階層に似ていますが、モジュールのディレクトリとモジュールのソース・コードのパッケージ階層のルートであるディレクトリとの間にディレクトリが割り込んでいる可能性があります。
たとえば、モジュール・ソース階層で、my.library
と呼ばれるモジュール内のcom.example.MyClass
というタイプのソース・ファイルは、my.library/src/main/java/com/example/MyClass.javaなどのファイルに格納できます。
モジュール・ソース・パス・オプション
--module-source-path
オプションは2つの形式で指定: 「モジュール固有のフォーム」では、コンパイルされるコードを含むモジュールごとにパッケージ・パスが与えられ、各モジュールのソース・パスがパターンで指定されるmodule-patternフォームが使用されます。 モジュール固有の形式は、通常、少数のモジュールのみが含まれる場合に使用する方が簡単です。モジュール数が多い場合、モジュール数が通常の方法で編成されているため、パターンで記述できます。
--module-source-path
オプションの複数のインスタンスが存在する可能性があります。各インスタンスには、モジュール・パス・フォームまたはモジュール固有フォームを使用し、次の制限があります:
- モジュール式フォームは最大で1回使用できます
- モジュール固有のフォームは、指定されたモジュールに対して最大で1回使用できます。
モジュール固有のフォームがモジュールに使用された場合、関連付けられた検索パスは、それ以外の場合にモジュールとの形式から推測されたパスをオーバーライドします。
モジュール固有のフォーム
モジュール固有のフォームでは、特定のモジュールに対して明示的な検索パスを指定できます。 フォーム:
--module-source-path
module-name=
file-path (path-separator file-path)*
パス・セパレータ文字は、Windowsでは;
で、それ以外は:
です。
ノート: これは、--patch-module
オプションに使用されるフォームに似ています。
モジュール形式
モジュール式パス形式は、通常の方法で整理された任意の数のモジュールについて、モジュール・ソース・パスの簡潔な仕様を可能にします。
--module-source-path
「パターン」
パターンは、次のルールで定義されます。これらのルールは、次の順に適用されます:
引数は、(Windowsの
;
およびそれ以外の:
)のパス・セパレータ文字で区切られた一連のセグメントとみなされます。フォームの中カッコを含む各セグメント
string1{alt1 ( ,alt2 )* } string2
次のように、"展開"によって形成される一連のセグメントにより置き換えられるとみなされます:
string1 alt1 string2 string1 alt2 string2 and so on...
中カッコがネストされている場合があります。
このルールは、このような中カッコの使用方法すべてに対して適用されます。
各セグメントにはアスタリスク(
*
)が1つ以上必要です。 セグメントにアスタリスクが付いていない場合は、そのセグメントはファイル・セパレータ文字とアスタリスクが追加されたものとみなされます。どのモジュールMでも、そのモジュールのソース・パスは、各セグメント内のアスタリスクをMというモジュール名に置き換えて取得した一連のセグメントから形成されます。
ノート: このコンテキストでは、アスタリスクは、モジュール名のパスの位置を示す特別なマーカーとしてのみ使用されます。 ほとんどのオペレーティング・システムで見られるように、ファイル名のワイルドカード文字として
*
を使用した場合と混同しないでください。
パッチ適用モジュール
javacは、ソース・フォームかコンパイル・フォームかに関係なく、すべてのコンテンツに対して--patch-module
オプションを使用して任意のモジュールへのパッチの適用を許可します。 実行時にJVMにパッチを適用するクラスの代替実装をコンパイルしたり、テスト時などの追加クラスをモジュールに注入する場合に、これを行います。
オプションの形式は次のとおりです:
--patch-module
module-name=
file-path (path-separator file-path )*
パス・セパレータ文字は、Windowsでは;
で、それ以外は:
です。 モジュールに指定されるパスは、モジュールのコンテンツのパッケージ階層のルートを指定する必要があります
このオプションは、どのモジュールに対しても最大で1回しか指定できません。 パス上のコンテンツは、パスの後ろの部分とパッチが適用されたモジュールの同名のコンテンツを非表示にします。
ソース・コードに複数のモジュールへパッチを適用する場合は、--module-source-path
も使用する必要があります。これにより、出力ディレクトリがモジュール階層に編成され、コンパイルされるモジュールのコンパイル済みクラス・ファイルを保持できるようになります。
アノテーションの処理
javac
コマンドは、注釈処理に対する直接サポートを提供します。
注釈処理のAPIは、javax.annotation.processing
およびjavax.lang.model
パッケージとそのサブパッケージ内に定義されています。
注釈処理のしくみ
-proc:none
オプションで注釈処理が無効になっている場合を除き、コンパイラは使用可能な注釈プロセッサを検索します。 検索パスは-processorpath
オプションを使用して指定できます。 パスが指定されていない場合は、ユーザー・クラス・パスが使用されます。 プロセッサは、サービス・プロバイダ構成ファイル(META-INF/services/javax.annotation.processing
)によって配置されます。 検索パス上のプロセッサ。 このようなファイルには、使用するすべての注釈プロセッサの名前を、1行に1つずつ含めてください。 または、-processor
オプションを使用して、プロセッサを明示的に指定できます。
コンパイラは、コマンド行のソース・ファイルやクラスをスキャンすることで、どのような注釈が存在しているかを確認し終わると、プロセッサに対して問合わせを行い、それらのプロセッサがどの注釈を処理できるのかを確認します。 一致するものが見つかった場合、そのプロセッサが呼び出されます。 各プロセッサは、自身が処理する注釈を要求できます。その場合、それらの注釈に対する別のプロセッサを見つける試みは行われません。 すべての注釈が要求された後に、コンパイラは追加のプロセッサを検索しません。
いずれかのプロセッサによって新しいソース・ファイルが生成されると、もう1ラウンド注釈処理が行われます。新しく生成されたソース・ファイルがスキャンされ、注釈が前と同じように処理されます。 以前のラウンドで呼び出されたプロセッサはすべて、後続のすべてのラウンドでも呼び出されます。 これが、新しいソース・ファイルが生成されなくなるまで続きます。
あるラウンドで新しいソース・ファイルが生成されなかった場合、注釈プロセッサがあと1回だけ呼び出され、残りの処理を実行する機会が与えられます。 最後に、-proc:only
オプションを使用しないかぎり、コンパイラによって元のソース・ファイルと、生成されたすべてのソース・ファイルがコンパイルされます。
コンパイルに含める追加のソース・ファイルを生成する注釈プロセッサを使用する場合は、モジュール宣言も生成されない場合に使用するために、新たに生成されるファイルに使用するデフォルト・モジュールを指定できます。 この場合、--default-module-for-created-files
オプションを使用します。
コンパイル環境およびランタイム環境。
ソース・ファイルおよび以前にコンパイルされたクラス・ファイルの宣言は、javac
自体の実行に使用された「ランタイム環境」とは別の「コンパイル環境」で分析されます。 --class-path
や--module-path
など、Java 「ランチャ」の多くのjavac
オプションと同様の名前のオプションは慎重に扱う必要がありますが、一般的にjavac
オプションは、ソース・ファイルがコンパイルされる環境にのみ影響し、javac
自体の操作には影響しないことを理解しておくことが重要です。
注釈プロセッサを使用する場合、コンパイル環境とランタイム環境の区別が重要になります。 注釈プロセッサはコンパイル環境に存在する要素(宣言)を処理しますが、注釈プロセッサはランタイム環境で実行されます。 注釈プロセッサに、モジュール内にないライブラリへの依存性がある場合、注釈プロセッサ自体とともにプロセッサ・パスにライブラリを配置できます。 (--processor-path
オプションを参照してください。) 注釈プロセッサおよびその依存性がモジュール内にある場合は、かわりにプロセッサ・モジュール・パスを使用する必要があります。 (--processor-module-path
オプションを参照してください。) これらの値が不十分な場合は、ランタイム環境をさらに構成する必要がある可能性があります。 これには2通りの方法があります。
javac
がコマンドラインから呼び出された場合、オプションの前に-J
を付けることで、基礎となるランタイムにオプションを渡すことができます。Java Virtual Machineのインスタンスを直接開始し、コマンドライン・オプションおよびAPIを使用して、
javac
がAPIのいずれかを介して起動できる環境を構成できます。
プラットフォームの以前のリリースのコンパイル
javac
では、--release
オプション、--source
/-source
および--target
/-target
オプションのいずれかを使用してプラットフォームの他のリリースで使用されるコードをコンパイルしたり、プラットフォーム・クラスを指定するための追加オプションとともに使用できます。
プラットフォームのリリースの必要性に応じて、使用可能なオプションのいくつかに制限があります。
JDK 8以前のリリースでコンパイルする場合、モジュール・システムで使用するためのオプションは一切使用できません。 これには、次のオプションがすべて含まれます:
--module-source-path
,--upgrade-module-path
,--system
,--module-path
,--add-modules
,--add-exports
,--add-opens
,--add-reads
,--limit-modules
,--patch-module
--source
/-source
または--target
/-target
オプションを使用する場合、起動クラスのパス・ファミリのオプションを使用して適切なプラットフォーム・クラスも設定する必要があります。JDK 9以降のリリースでコンパイルする場合、ブート・クラス・パスの構成を目的としたオプションを使用することはできません。 これには、次のオプションがすべて含まれます:
-Xbootclasspath/p:
,-Xbootclasspath
,-Xbootclasspath/a:
,-endorseddirs
,-Djava.endorsed.dirs
,-extdirs
,-Djava.ext.dirs
,-profile
--source
/-source
または--target
/-target
オプションを使用する場合、--system
オプションを使用して適切なプラットフォーム・クラスも設定し、インストールされた適切なリリースのJDKのロケーションを指定する必要があります。
--release
オプションを使用する場合、そのリリースでサポートされているドキュメント化されたAPIのみを使用できます。内部クラスへのアクセスのためにカプセル化を解除するオプションは使用できません。
API
javac
コンパイラは、3つの異なる方法でAPIを使用して起動できます:
- JavaコンパイラAPI
- これにより、メモリー・バッファやその他の標準でないファイル・システムで提供されているソース・ファイルをコンパイルする機能を含め、コンパイラの起動を最も柔軟な方法で実現できます。
- The ToolProvider API
javac
用ToolProvider
は、ToolProvider.findFirst("javac")
をコールして取得できます。 このメソッドは、コマンド行ツールに相当する機能を持つオブジェクトを返します。ノート: このAPIを、
javax.tools
パッケージ内の同様の名前のAPIと混同しないでください。javac
「レガシーAPI」- このAPIは下位互換性のためにのみ保持されます。 すべての新規コードは、JavaコンパイラAPIまたはToolProvider APIのいずれかを使用する必要があります。
ノート: 名前がcom.sun.tools.javac
で始まるパッケージ(com.sun.tools.javac
のサブパッケージ)に含まれるその他のすべてのクラスやメソッドは、厳密に内部用であり、いつでも変更される可能性があります。
-Xlintキーの使用例
cast
不要で冗長なキャストについて警告します。たとえば:
String s = (String) "Hello!"
classfile
- クラス・ファイルの内容に関する問題について警告します。
deprecation
非推奨アイテムの使用について警告します。 たとえば:
java.util.Date myDate = new java.util.Date(); int currentDay = myDate.getDay();
メソッド
java.util.Date.getDay
はJDK 1.1以降は推奨されていません。dep-ann
@deprecated
Javadocコメントに文書化されているが、@Deprecated
注釈がないアイテムについて警告します。次に例を示します:/** * @deprecated As of Java SE 7, replaced by {@link #newMethod()} */ public static void deprecatedMethod() { } public static void newMethod() { }
divzero
定整数0による除算について警告します。たとえば:
int divideByZero = 42 / 0;
empty
if
文の後に空の文について警告します。次に例を示します:class E { void m() { if (true) ; } }
fallthrough
fall-through caseのswitchブロックをチェックし、検出されたものに対して警告メッセージを表示します。 永久的なケースとは、ブロックの最後のケース以外のスイッチ・ブロックのケースのことであり、そのコードに
break
文が含まれていないため、コードの実行がそのケースから次のケースに渡される可能性があります。 たとえば、このスイッチ・ブロックのcase 1ラベルに続くコードは、break
文で終わっていません:switch (x) { case 1: System.out.println("1"); // No break statement here. case 2: System.out.println("2"); }
このコードのコンパイル時に
-Xlint:fallthrough
オプションが使用されていた場合、コンパイラは該当するcaseの行番号とともに、caseにfall-throughする可能性があることを示す警告を発行します。finally
通常は完了できない
finally
句について警告します。次に例を示します:public static int m() { try { throw new NullPointerException(); } catch (NullPointerException(); { System.err.println("Caught NullPointerException."); return 1; } finally { return 0; } }
この例では、コンパイラは
finally
ブロックに関する警告を生成します。int
メソッドが呼び出されると、0の値が返されます。finally
ブロックは、try
ブロックが終了すると実行されます。 この例では、catch
ブロックに制御が移されると、int
メソッドは終了します。 ただし、finally
ブロックは実行する必要があるため、制御がメソッドの外部に転送されていても実行されます。options
- コマンド行オプションの使用に関する問題について警告します。 「プラットフォームの以前のリリースのコンパイル」を参照してください。
overrides
メソッドのオーバーライドに関する問題について警告します。 たとえば、次の2つのクラスがあるとします。
public class ClassWithVarargsMethod { void varargsMethod(String... s) { } } public class ClassWithOverridingMethod extends ClassWithVarargsMethod { @Override void varargsMethod(String[] s) { } }
コンパイラは次のような警告を生成します。
warning: [override] varargsMethod(String[]) in ClassWithOverridingMethod overrides varargsMethod(String...) in ClassWithVarargsMethod; overriding method is missing '...'
コンパイラが
varargs
メソッドを検出すると、varargs
の仮パラメータを配列に変換します。 メソッドClassWithVarargsMethod.varargsMethod
では、コンパイラはvarargs
仮パラメータString... s
を仮パラメータString[] s
に変換します。これは、メソッドClassWithOverridingMethod.varargsMethod
の仮パラメータと一致する配列です。 その結果、この例ではコンパイルが行われます。path
コマンド行のクラス・パス、ソース・パスおよびその他のパスとして指定された無効なパス要素と存在しないパス・ディレクトリについて警告します。 このような警告を
@SuppressWarnings
注釈で抑制することはできません。 たとえば:LinuxおよびmacOS:
javac -Xlint:path -classpath /nonexistentpath Example.java
Windows:
javac -Xlint:path -classpath C:\nonexistentpath Example.java
processing
注釈処理に関する問題について警告します。 注釈があるクラスがあり、そのタイプの注釈を処理できない注釈プロセッサを使用すると、コンパイラによってこの警告が生成されます。 たとえば、次のものは簡単な注釈プロセッサです:
ソース・ファイルAnnoProc.java:
import java.util.*; import javax.annotation.processing.*; import javax.lang.model.*; import javax.lang.model.element.*; @SupportedAnnotationTypes("NotAnno") public class AnnoProc extends AbstractProcessor { public boolean process(Set<? extends TypeElement> elems, RoundEnvironment renv){ return true; } public SourceVersion getSupportedSourceVersion() { return SourceVersion.latest(); } }
ソース・ファイルAnnosWithoutProcessors.java:
@interface Anno { } @Anno class AnnosWithoutProcessors { }
次のコマンドは、注釈プロセッサ
AnnoProc
をコンパイルしたあと、ソース・ファイルAnnosWithoutProcessors.java
に対してこの注釈プロセッサを実行します。javac AnnoProc.java javac -cp . -Xlint:processing -processor AnnoProc -proc:only AnnosWithoutProcessors.java
ソース・ファイル
AnnosWithoutProcessors.java
に対して注釈プロセッサを実行すると、コンパイラは次の警告を生成します。warning: [processing] No processor claimed any of these annotations: Anno
この問題を解決するには、
AnnosWithoutProcessors
クラスで定義および使用されている注釈の名前をAnno
からNotAnno
に変更します。rawtypes
raw型に対する未チェック操作について警告します。 次の文では、
rawtypes
警告が生成されます。void countElements(List l) { ... }
次の例は、
rawtypes
警告が生成されません。:void countElements(List<?> l) { ... }
List
はraw型です。 ただし、List<?>
はバインドなしのパラメータ化されたワイルドカード型です。List
はパラメータ化されたインタフェースなので、必ずその型引数を指定するようにしてください。 この例では、List
の仮引数はバインドなしのワイルドカード(?
)を使用してその仮型パラメータとして指定されています。つまり、countElements
メソッドはList
インタフェースの任意のインスタンス化を受け入れることができます。serial
直列化可能クラスで欠落している
serialVersionUID
定義について警告します。 たとえば:public class PersistentTime implements Serializable { private Date time; public PersistentTime() { time = Calendar.getInstance().getTime(); } public Date getTime() { return time; } }
コンパイラで次のような警告が生成されます。
warning: [serial] serializable class PersistentTime has no definition of serialVersionUID
直列化可能クラスが
serialVersionUID
という名前のフィールドを明示的に宣言しない場合、直列化ランタイム環境は「Javaオブジェクト直列化仕様」で説明されているように、クラスの様々な側面に基づいて、クラスのserialVersionUID
のデフォルト値を計算します。 ただし、すべての直列化可能クラスでserialVersionUID
値を明示的に宣言することを強くお薦めします。これは、serialVersionUID
値の計算のデフォルト・プロセスは、コンパイラ実装によって異なる可能性があるクラスの詳細に非常に敏感であるためです。 そのため、直列化復元中に予期しないInvalidClassExceptions
が発生する可能性があります。 様々なjavaコンパイラ実装間でserialVersionUID
値の一貫性を確保にするには、直列化可能クラスでserialVersionUID
値を明示的に宣言しなければいけません。static
静的変数の使用に関する問題について警告します。たとえば:
class XLintStatic { static void m1() { } void m2() { this.m1(); } }
コンパイラで次のような警告が生成されます。
warning: [static] static method should be qualified by type name, XLintStatic, instead of by an expression
この問題を解決するために、次のように
static
メソッドm1
を呼び出すことができます。XLintStatic.m1();
あるいは、
static
キーワードをメソッドm1
の宣言から削除することもできます。try
try-with-resources文を含む、
try
ブロックの使用に関する問題を警告します。 たとえば、try
ブロックで宣言されたリソースac
が使用されていないため、次の文に対して警告が生成されます。try ( AutoCloseable ac = getResource() ) { // do nothing}
unchecked
Java言語仕様で指定されている未チェック変換警告の詳細を示します。たとえば:
List l = new ArrayList<Number>(); List<String> ls = l; // unchecked warning
型の消去中に、型
ArrayList<Number>
およびList<String>
はそれぞれArrayList
およびList
になります。ls
コマンドはパラメータ化された型List<String>
を持ちます。l
によって参照されているList
がls
に代入されている場合、コンパイラは非チェック警告を生成します。 コンパイル時に、コンパイラとJVMはl
がList<String>
型を表すかどうかを判断できません。 この場合、l
はList<String>
型を表しません。 結果として、ヒープ汚染が発生します。ヒープ汚染状態が発生するのは、
List
オブジェクトl
(そのstatic型はList<Number>
)が別のList
オブジェクトls
(異なるstatic型List<String>
を持つ)に代入される場合です。 しかし、コンパイラはこの代入をいまだに許可しています。 この代入を許可する必要があるのは、ジェネリックスをサポートしないJava SEのリリースとの下位互換性を確保するためです。 型消去のために、List<Number>
とList<String>
はList
になります。 その結果、コンパイラはオブジェクトl
(List
というraw型を持つ)をオブジェクトls
に代入することを許可します。varargs
可変引数(
varargs
)メソッド(特に、再対応できない引数を含むメソッド)の安全でない使用について警告します。次に例を示します:public class ArrayBuilder { public static <T> void addToList (List<T> listArg, T... elements) { for (T x : elements) { listArg.add(x); } } }
非具象化可能型とは、実行時に型情報が完全には使用可能になっていない型のことです。
コンパイラは、メソッド
ArrayBuilder.addToList
の定義に関する次の警告を生成します。warning: [varargs] Possible heap pollution from parameterized vararg type T
コンパイラがvarargsメソッドを検出すると、
varargs
仮パラメータを配列に変換します。 しかし、Javaプログラミング言語では、パラメータ化された型の配列の作成は許可されません。 メソッドArrayBuilder.addToList
では、コンパイラはvarargs
の仮パラメータT... elements
要素を仮パラメータT[] elements
要素(配列)に変換します。 しかし、型消去のために、コンパイラはvarargs
の仮パラメータをObject[]
要素に変換します。 その結果、ヒープ汚染が発生する可能性があります。