javacコマンド

機械翻訳について

名前

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つの方法があります:

コマンド行または引数ファイルに指定されたソース・ファイルの順序は、重要ではありません。javacは、グループとしてファイルをまとめてコンパイルし、各種ソース・ファイル内の宣言間の依存関係を自動的に解決します。

javacでは、「ソース・コードの契約」で説明されているように、ソース・ファイルはファイル・システム上の1つ以上のディレクトリ階層に配置されると想定しています。

ソース・ファイルをコンパイルするには、ソース・ファイルのコードで使用、拡張または実装されているすべてのクラスまたはインタフェースの宣言を、javacで検索する必要があります。 これにより、javacでは、これらのクラスおよびインタフェースにアクセスする権限がコードにあることを確認できます。 これらのクラスおよびインタフェースのソース・ファイルを明示的に指定するかわりに、コマンド行オプションを使用して、ソース・ファイルの検索場所をjavacに指定できます。 これらのソース・ファイルを以前にコンパイルしたことがある場合は、オプションを使用して、対応するクラス・ファイルの検索場所をjavacに指示できます。 すべてのオプションの名前が"path"で終わるオプションについては、「標準オプション」で説明し、「コンパイルの構成」および「モジュール、パッケージおよびタイプの宣言の検索」でさらに説明します。

デフォルトでは、javacは各ソース・ファイルをソース・ファイルと同じディレクトリのクラス・ファイルにコンパイルします。 ただし、「標準オプション」で記述されている-dオプションを使用して別の宛先ディレクトリを指定することをお薦めします。

コマンドラインoptionsおよび「環境変数」では、javacが次の様々なタスクを実行する方法も制御します:

javacでは「プラットフォームの以前のリリースのコンパイル」がサポートされており、多くのAPIの1つを使用してJavaコードから起動することもできます

Options

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コマンドを作成できます。 「コマンド行引数ファイル」を参照してください。
-Akey[=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
その他の一連のオプションのシノプシスを出力します。
-implicit:[none, class]

暗黙的に参照されるファイルのクラス・ファイルを生成するかどうかを指定します:

  • -implicit:class ---クラス・ファイルを自動的に生成します。

  • -implicit:none ---クラス・ファイルの生成を抑制します。

このオプションが指定されない場合、デフォルトでクラス・ファイルが自動的に生成されます。 この場合、注釈処理を行うときにクラス・ファイルが生成された場合、コンパイラは警告を発行します。 -implicitオプションが明示的に設定されている場合、警告は発行されません。 「モジュール、パッケージおよびタイプの宣言の検索」を参照してください。

-Joption

optionをランタイム・システムに渡します。ここで、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]
注釈処理とコンパイルが実行されるかどうかを制御します。-proc:noneは、注釈処理なしでコンパイルが実行されることを意味します。-proc:onlyは、注釈処理のみが実行され、後続のコンパイルは実行されないことを意味します。
-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の説明を参照してください。

--doclint-format [html4|html5]
ドキュメンテーション・コメントの書式を指定します。
--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の前にハイフン(-)を指定すると、1つまたは複数の指定されたパッケージに関するチェックを無効にできます。
-Xlint
推奨されるすべての警告を有効にします。 このリリースでは、利用可能なすべての警告を有効にすることが推奨されています。
-Xlint:[-]key(,[-]key)*

有効または無効にする警告をカンマで区切って指定します。 指定した警告を無効にするには、キーの前にハイフン(-)を指定します。

サポートされているkeyの値は、次のとおりです。

  • all: すべての警告を有効にします。

  • auxiliaryclass: ソース・ファイルでは非表示で、他のファイルから使用される補助クラスについて警告します。

  • cast: 不要なキャストの使用について警告します。

  • classfile: クラス・ファイルの内容に関連した問題について警告します。

  • deprecation: 非推奨項目の使用について警告します。

  • dep-ann: javadocで非推奨とマークされているのに@Deprecated注釈を使用していない項目について警告します。

  • divzero: 定整数0による除算について警告します。

  • empty: if以降が空の文であることについて警告します。

  • exports: モジュールのエクスポートに関する問題について警告します。

  • fallthrough: switch文の1つのcaseから次へのフォール・スルーについて警告します。

  • finally: 通常終了しないfinally句について警告します。

  • module: モジュール・システム関連の問題について警告します。

  • opens: モジュールのオープンに関する問題について警告します。

  • options: コマンド行オプションの使用に関する問題について警告します。

  • overloads: メソッドのオーバーロードに関する問題について警告します。

  • overrides: メソッドのオーバーライドに関する問題について警告します。

  • path: コマンド行の無効なパス要素について警告します。

  • processing: 注釈処理に関する問題について警告します。

  • rawtypes: raw型の使用について警告します。

  • removal: 削除用にマークされたAPIの使用について警告します。

  • requires-automatic: requires句内の自動モジュールの使用について開発者に警告します。

  • requires-transitive-automatic: requires transitive内の自動モジュールについて警告します。

  • serial: シリアル・バージョンIDを指定しない直列化可能クラスについて警告します。 また、直列化可能要素からpublic以外のメンバーへのアクセスについて警告します。

  • static: インスタンスを使用したstaticメンバーへのアクセスについて警告します。

  • try: tryブロック(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.javaにRetentionPolicy.CLASSまたはRetentionPolicy.RUNTIMEのある注釈が含まれる場合にのみ、package-info.classファイルを生成します。
-Xplugin:name args
実行されるプラグインの名前およびオプションの引数を指定します。 argsが指定されている場合、nameとargsは引用符で囲むか、それ以外の場合は名前とすべての引数の間にある空白文字をエスケープする必要があります。 プラグインのAPIの詳細は、jdk.compiler/com.sun.source.util.Plugin APIドキュメントを参照してください。
-Xprefer:[source, newer]

次のオプションのいずれかを使用して、暗黙的にコンパイルされるクラスについて、てソース・ファイルとクラス・ファイルの両方が見つかった場合、どのファイルを読み取るかを指定します。 「モジュール、パッケージおよびタイプの宣言の検索」を参照してください。

  • -Xprefer:newer: ある型に対するソース・ファイルとクラス・ファイルの新しい方が読み取られます(デフォルト)。

  • -Xprefer:source : ソース・ファイルが読み取られます。 SOURCEの保存ポリシーを使用して宣言された注釈に任意の注釈プロセッサがアクセスできるようにする場合は、-Xprefer: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という名前のファイルを作成します:

Oracle Solaris、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では、ファイルシステムのディレクトリ内のソース・ファイルの物理的な配置によってクラスがパッケージに反映され、パッケージがモジュールにもミラー化されると想定しています。

モジュール名とパッケージ名は小文字で始まり、そのクラス名は大文字で始まります。

パッケージのソース・コードの配置

クラスとインタフェースをパッケージに編成すると、そのパッケージはディレクトリとして表され、すべてのサブパッケージはサブディレクトリとして表されます。

次に例を示します。

ディレクトリまたはサブディレクトリ内では、.javaファイルは対応するパッケージまたはサブパッケージ内のクラスおよびインタフェースを表します。

次に例を示します。

状況によっては、前述のように構造化された個別のディレクトリ、およびjavacに指定されたディレクトリの集約リストにコードを分割すると便利です。

モジュールのソース・コードの配置

Java言語では、モジュールとは再利用を目的として設計されたパッケージの集合のことです。 クラスやインタフェースの.javaファイルに加え、各モジュールにはmodule-info.javaと呼ばれるソース・ファイルがあります。このソース・ファイルは次のとおりです:

  1. モジュール名を宣言

  2. には、モジュール(他のモジュールで再利用できるようにします)によってエクスポートされたパッケージがリストされます。

  3. モジュール(エクスポートしたパッケージを再利用)で必要なその他のモジュールを一覧表示します。

パッケージがモジュールに編成されると、モジュールは、モジュール内のパッケージを表す1つ以上のディレクトリによって表され、その中にmodule-info.javaファイルが含まれます。 モジュール名と同じ名前の単一のディレクトリをモジュール(例:前述の「パッケージ階層」)のパッケージを表すディレクトリ・ツリーとともにmodule-info.javaファイルを格納するために、これは便利ですが、必須ではありません。 モジュールのソース・コードの正確な配置は、通常、開発環境(IDE)またはビルド・システムに採用される規則によって決定されます。

次に例を示します。

開発環境では、モジュールに指定されたディレクトリとjavacによって読み取られるソース・ファイルの間に、いくつかのディレクトリ階層が規定される場合があります。

次に例を示します。

コンパイルの構成

この項では、基本的なコンパイルを実行するようにjavacを構成する方法について説明します。

モジュールをサポートするリリースのプラットフォーム用にコンパイルする場合の詳細は、「モジュール・システムの構成」を参照してください。

ソース・ファイル

コンパイル・エラーがない場合、対応するクラス・ファイルは「出力ディレクトリ」内に配置されます。

システムによっては、コマンドラインに入力できる容量が制限される場合があります。これらの制限を回避するには、「引数ファイル」を使用できます。

モジュールのコードをコンパイルする際、--moduleまたは-mオプションを使用してソース・ファイルを間接的に指定することもできます。「標準オプション」を参照してください。

Output Directory

これは通常、複数のモジュールからソース・コードをコンパイルしていないかぎり、「パッケージ階層」内に編成されます。その場合、「モジュール階層」として編成されます。

コンパイルが完了している場合に、1つ以上のモジュールをコンパイルすると、Java 「ランチャ」のモジュール・パスに出力ディレクトリを配置できます。格納できない場合は、Javaランチャのクラス・パスに出力ディレクトリを配置できます。

プリコンパイル済コード

コンパイルするコードがプラットフォームで提供される以上のライブラリを参照している場合があります。 その場合は、これらのライブラリをクラスパスまたはモジュール・パスに配置する必要があります。 ライブラリ・コードがモジュールにない場合は、クラスパスに配置し、モジュールにある場合はモジュール・パスに配置します。

ノート: クラス・パスおよびモジュール・パスのオプションは相互に排他的ではありませんが、1つ以上のモジュールのコードをコンパイルするときにクラス・パスを指定することは一般的ではありません。

追加ソース・ファイル

コンパイルするコードは、コマンドラインで指定されていない追加のソース・ファイル内のタイプを参照している可能性があります。 その場合は、ソース・パスまたはモジュール・パスのいずれかにソース・ファイルを置く必要があります。 次のオプションのうち1つだけを指定できます: モジュールのコードをコンパイルしていない場合、または1つのモジュールのコードのみをコンパイルしている場合はソース・パスを使用します。複数のモジュールのコードをコンパイルしている場合は、モジュール・ソース・パスを使用します。

追加のソース・ファイル内のタイプを参照できるようにし、それらをコンパイルできないようにするには、-implicitオプションを使用します。

ノート: 複数のモジュールに対してコードをコンパイルする場合は、常にモジュールのソース・パスを指定し、コマンドラインで指定されるすべてのソース・ファイルがモジュールのソース・パス上のいずれかのディレクトリに存在するか、またはそのサブディレクトリに存在する必要があります。

複数のソース・ファイルをコンパイルする例

この例では、greetingsパッケージ内のAloha.java、GutenTag.java、Hello.javaおよびHi.javaソース・ファイルをコンパイルします。

Oracle Solaris、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

ユーザー・クラス・パスの指定例

前の例のいずれかのソース・ファイルの変更後、それを再コンパイルします。

Oracle Solaris、LinuxおよびmacOS:

pwd
/examples
javac greetings/Hi.java

Windows:

C:\>cd
\examples
C:\>javac greetings\Hi.java

greetings.Hiは、greetingsパッケージ内の他のクラスを参照しているため、コンパイラはこれらのその他のクラスを探す必要があります。 前の例は、デフォルトのユーザー・クラス・パスが、パッケージ・ディレクトリを含むディレクトリであるため機能します。 現在のディレクトリに関係なく、このファイルを再コンパイルする場合、CLASSPATHを設定して、例のディレクトリをユーザー・クラス・パスに追加します。 この例では-classpathオプションを使用します。

Oracle Solaris、LinuxおよびmacOS:

javac -classpath /examples /examples/greetings/Hi.java

Windows:

C:\>javac -classpath \examples \examples\greetings\Hi.java

greetings.Hiを変更してバナー・ユーティリティを使用するようにした場合、このユーティリティもユーザー・クラス・パスを通じてアクセスできる必要があります。

Oracle Solaris、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クラスが使用するクラスにアクセスする必要があります。

Oracle Solaris、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は次のパスとロケーションを遅延スキャンして、コンパイルで使用するモジュールを判断します。

どのモジュールについても、スキャン中に最初に発生したモジュールのシャドウは(hides)で、同様の名前のモジュールのその後の外観です。 モジュールの検索中、javacは、モジュールによってエクスポートされたパッケージを判別し、各モジュールにモジュールのコンテンツへのパッケージ指向パスを関連付けることができます。 以前にコンパイルされたモジュールの場合、このパスは通常、ディレクトリまたは内部ディレクトリに類似した階層(JARファイルなど)を提供するファイルのいずれかの単一エントリになります。 したがって、モジュールによってエクスポートされることがわかっているパッケージ内の型を検索する場合、javacではその宣言を直接効率的に検索できます。

モジュールの宣言の検索

モジュールが以前にコンパイルされている場合、モジュール宣言は、モジュールのコンテンツのためのパッケージ階層のルートにあるmodule-info.classという名前のファイルにあります。

モジュールが現在コンパイル中のモジュールの1つである場合、モジュール宣言は、クラス出力ディレクトリ内のモジュールのパッケージ階層のルートにあるmodule-info.classという名前のファイルか、ソース・パス上のいずれかのロケーションにあるmodule-info.javaという名前のファイルか、またはモジュールのモジュール・ソース・パスの1つになります。

参照がモジュールにない場合のタイプの宣言の検索

モジュール内にないコードで参照されるタイプを検索すると、javacは次の場所を参照します:

クラスパスまたはソース・パス(あるいはその両方)でタイプを検索する際に、コンパイルされたクラス・ファイルとソース・ファイルの両方が見つかった場合は、最後に変更されたファイルがデフォルトで使用されます。 新しいソース・ファイルはコンパイルされ、以前にコンパイルされたファイルのバージョンをオーバーライドする場合があります。 デフォルトの動作は、-Xpreferオプションを使用してオーバーライドできます。

参照がモジュール内にある場合のタイプの宣言の検索

モジュール内のコードで参照される型を検索する場合、javacは、包含するモジュールの宣言を調べて、包含するモジュールが参照可能な別のモジュールからエクスポートされた型がパッケージ内にあるかどうかを判断します。 その場合、javacはそのモジュールの定義を単純かつ直接的に見つけて、必要なタイプの定義を見つけます。 モジュールがコンパイル中のモジュールのもう1つでないかぎり、javacはコンパイル済クラス・ファイルのみを検索します。 つまり、javacでは、プラットフォーム・モジュールのソース・ファイルやモジュール・パスのモジュールは検索されません。

参照される型が他の判読可能なモジュール内にない場合、javacはコンパイル中のモジュールを調べて、型の宣言を見つけます。javacでは、次のように型の宣言が検索されます:

ディレクトリ階層

javacでは、一般的に、ソース・ファイルとコンパイル済クラス・ファイルは、ファイル・システムのディレクトリ階層、またはJARファイルなどの内部ディレクトリ階層でサポートされるファイル・タイプに整理されると想定しています。 3種類の異なる階層がサポートされています: 「パッケージ階層」、「モジュール階層」および「モジュール・ソース階層」。

javacは、ソース・コードの編成に関してかなり緩和されていますが、ソースが1つまたはパッケージ階層に編成される想定に加えて、一般に開発環境およびビルド・ツールによって規定される組織や、一般に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オプションの複数のインスタンスが存在する可能性があります。各インスタンスには、モジュール・パス・フォームまたはモジュール固有フォームを使用し、次の制限があります:

モジュール固有のフォームがモジュールに使用された場合、関連付けられた検索パスは、それ以外の場合にモジュールとの形式から推測されたパスをオーバーライドします。

モジュール固有のフォーム

モジュール固有のフォームでは、特定のモジュールに対して明示的な検索パスを指定できます。 フォーム:

パス・セパレータ文字は、Windowsでは;で、それ以外は:です。

ノート: これは、--patch-moduleオプションに使用されるフォームに似ています。

モジュール形式

モジュール式パス形式は、通常の方法で整理された任意の数のモジュールについて、モジュール・ソース・パスの簡潔な仕様を可能にします。

パターンは、次のルールで定義されます。これらのルールは、次の順に適用されます:

パッチ適用モジュール

javacは、ソース・フォームかコンパイル・フォームかに関係なく、すべてのコンテンツに対して--patch-moduleオプションを使用して任意のモジュールへのパッチの適用を許可します。 実行時にJVMにパッチを適用するクラスの代替実装をコンパイルしたり、テスト時などの追加クラスをモジュールに挿入する場合に、これを行います。

オプションの形式は次のとおりです:

パス・セパレータ文字は、Windowsでは;で、それ以外は:です。 モジュールに指定されるパスは、モジュールのコンテンツのパッケージ階層のルートを指定する必要があります

このオプションは、どのモジュールに対しても最大で1回しか指定できません。 パス上のコンテンツは、パスの後ろの部分とパッチが適用されたモジュールの同名のコンテンツを非表示にします。

ソース・コードに複数のモジュールへパッチを適用する場合は、--module-source-pathも使用する必要があります。これにより、出力ディレクトリがモジュール階層に編成され、コンパイルされるモジュールのコンパイル済みクラス・ファイルを保持できるようになります。

注釈処理

javacコマンドは、注釈処理に対する直接サポートを提供します。

注釈処理のAPIは、javax.annotation.processingおよびjavax.lang.modelパッケージとそのサブパッケージ内に定義されています。

注釈処理のしくみ

-proc:noneオプションによって注釈処理が無効化されないかぎり、コンパイラは使用可能なすべての注釈プロセッサを検索します。 検索パスは-processorpathオプションを使用して指定できます。 パスが指定されていない場合は、ユーザー・クラス・パスが使用されます。 プロセッサの検索は、META-INF/services/javax.annotation.processing.Processorという名前のサービス・プロバイダ構成ファイルを使用して行われます。 検索パス上のプロセッサ。 このようなファイルには、使用するすべての注釈プロセッサの名前を、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通りの方法があります。

  1. javacがコマンドラインから呼び出された場合、オプションの前に-Jを付けることで、基礎となるランタイムにオプションを渡すことができます。 (-Jオプションを参照してください。)

  2. Java Virtual Machineのインスタンスを直接開始し、コマンドライン・オプションおよびAPIを使用して、javacがAPIのいずれかを介して起動できる環境を構成できます。

プラットフォームの以前のリリースのコンパイル

javacでは、--releaseオプション、--source/-sourceおよび--target/-targetオプションのいずれかを使用してプラットフォームの他のリリースで使用されるコードをコンパイルしたり、プラットフォーム・クラスを指定するための追加オプションとともに使用できます。

プラットフォームのリリースの必要性に応じて、使用可能なオプションのいくつかに制限があります。

--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文が含まれていないため、コードの実行がそのケースから次のケースに渡される可能性があります。 たとえば、このswitchブロック内の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注釈で抑制することはできません。 次に例を示します。

  • Oracle Solaris、LinuxおよびmacOS: javac -Xlint:path -classpath /nonexistentpath Example.java

  • Windows: javac -Xlint:path -classpath C:\nonexistentpath Example.java

processing

注釈処理に関する問題について警告します。 コンパイラがこの警告を生成するのは、注釈を含むクラスがあり、そのタイプの例外を処理できない注釈プロセッサを使用している場合です。 簡単な注釈プロセッサの例を次に示します。

ソース・ファイルAnnocProc.java:

import java.util.*;
import javax.annotation.processing.*;
import javax.lang.model.*;
import javaz.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[]要素に変換します。 その結果、ヒープ汚染が発生する可能性があります。