javac

options

コマンド行オプション。「オプション」を参照してください。

sourcefiles

コンパイルされる1つ以上のソース・ファイル(MyClass.javaなど)。

classes

注釈の処理対象となる1つ以上のクラス(MyPackage.MyClassなど)。

@argfiles

オプションとソース・ファイルを一覧表示した1つ以上のファイル。このファイルの中では、-Jオプションは指定できません。「コマンド行引数ファイル」を参照してください。

• 「クロスコンパイル・オプション」も参照してください

• 「非標準オプション」も参照してください

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注釈では抑制できません。例:

javac -Xlint:path -classpath /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

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[]要素に変換します。その結果、ヒープ汚染が発生する可能性があります。

例1 - 単一の引数ファイル

すべてのjavac引数を保持するargfileという名前の単一の引数ファイルを使用できます。

javac @argfile

この引数ファイルには、例2で示されている両方のファイルの内容を格納できます。

例2 - 2つの引数ファイル

たとえば、javacオプション用に1ファイル、ソース・ファイル名用に1ファイルというように、2つの引数ファイルを作成できます。次のリストでは、行の継続文字を使用していないことに注意してください。

次を含むoptionsというファイルを作成します。

-d classes
-g
-sourcepath /java/pubs/ws/1.3/src/share/classes

次を含むclassesというファイルを作成します。

MyClass1.java
MyClass2.java
MyClass3.java

次に、次のようにjavacコマンドを実行します。

javac @options @classes

例3 - パス付きの引数ファイル

引数ファイルにはパスを指定できますが、ファイル内のすべてのファイル名は、現在の作業ディレクトリに相対的になります(path1やpath2でなく)。

javac @path1/options @path2/classes

-bootclasspathオプションと-extdirsオプションを使用すると、別のブートストラップ・クラスや拡張機能クラスを指定できます。「クロスコンパイル・オプション」を参照してください。

型の検索に成功したときに得られる結果は、クラス・ファイル、ソース・ファイル、またはその両方である場合があります。両方が見つかった場合、そのどちらを使用すべきかを-Xpreferオプションでコンパイラに指示できます。newerが指定された場合、コンパイラは2つのファイルの新しい方を使用します。sourceが指定された場合、コンパイラはソース・ファイルを使用します。デフォルトはnewerです。

型の検索自体によって、または-Xpreferオプションが設定された結果として、必要な型のソース・ファイルが見つかった場合、コンパイラはそのソース・ファイルを読み取り、必要な情報を取得します。デフォルトで、コンパイラは、ソース・ファイルもコンパイルします。-implicitオプションを使えばその動作を指定できます。noneを指定した場合、ソース・ファイルのクラス・ファイルは生成されません。classを指定した場合、ソース・ファイルのクラス・ファイルが生成されます。

コンパイラは、注釈処理の完了後に、ある型情報の必要性を認識しない場合があります。型情報がソース・ファイル内に見つかり、かつ-implicitオプションが指定されていない場合、コンパイラは、そのファイルが注釈処理の対象とならずにコンパイルされることを警告します。この警告を無効にするには、(そのファイルが注釈処理の対象となるように)そのファイルをコマンド行に指定するか、あるいはそのようなソース・ファイルに対してクラス・ファイルを生成すべきかどうかを-implicitオプションを使って指定します。

例1 - 単純なプログラムのコンパイル

この例では、greetingsディレクトリ内のHello.javaソース・ファイルをコンパイルする方法を示しています。Hello.javaに定義されているクラスは、greetings.Helloと呼ばれます。greetingsディレクトリは、ソース・ファイルとクラス・ファイルの両方のパッケージ・ディレクトリで、現在のディレクトリのすぐ下にあります。これにより、デフォルトのユーザー・クラス・パスを使用できます。また、-dオプションを使用して別の出力先ディレクトリを指定する必要もありません。

Hello.java内のソース・コード:

package greetings;
 
public class Hello {
    public static void main(String[] args) {
        for (int i=0; i < args.length; i++) {
            System.out.println("Hello " + args[i]);
        }
    }
}

greetings.Helloのコンパイル:

javac greetings/Hello.java

greetings.Helloを実行します。

java greetings.Hello World Universe Everyone
Hello World
Hello Universe
Hello Everyone

例2 - 複数のソース・ファイルのコンパイル

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

% javac greetings/*.java
% ls greetings
Aloha.class         GutenTag.class      Hello.class         Hi.class
Aloha.java          GutenTag.java       Hello.java          Hi.java

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

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

pwd
/examples
javac greetings/Hi.java

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

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

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

javac -classpath /examples:/lib/Banners.jar \
            /examples/greetings/Hi.java

greetingsパッケージのクラスを実行するには、プログラムがgreetingsパッケージおよびgreetingsクラスが使用するクラスにアクセスする必要があります。

java -classpath /examples:/lib/Banners.jar greetings.Hi

例4 - ソース・ファイルとクラス・ファイルの分離

次の例では、javacを使用して、JVM 1.7上で動作するコードをコンパイルします。

javac -source 1.7 -target 1.7 -bootclasspath jdk1.7.0/lib/rt.jar \ 
-extdirs "" OldCode.java

-source 1.7オプションにより、OldCode.javaのコンパイルにはリリース1.7(または7)のJavaプログラミング言語が使用されます。-target 1.7オプションにより、JVM 1.7と互換性のあるクラス・ファイルが生成されます。ほとんどの場合、-targetオプションの値は-sourceオプションの値になります。この例では、-targetオプションを省略できます。

-bootclasspathオプションを使用して、正しいバージョンのブートストラップ・クラス(rt.jarライブラリ)を指定する必要があります。指定しなかった場合は、コンパイラによって次の警告が生成されます。

javac -source 1.7 OldCode.java
warning: [options] bootstrap class path not set in conjunction with 
-source 1.7

適切なバージョンのブートストラップ・クラスを指定しない場合、コンパイラは古い言語仕様(この例では、バージョン1.7のJavaプログラミング言語)を新しいブートストラップ・クラスと組み合せて使用します。その結果、存在しないメソッドへの参照が含まれていることがあるため、クラス・ファイルが古いプラットフォーム(この場合はJava SE 7)で動作しない可能性があります。

例5 - クロス・コンパイル

この例では、javacを使用して、JVM 1.7上で動作するコードをコンパイルします。

javac -source 1.7 -target 1.7 -bootclasspath jdk1.7.0/lib/rt.jar \
            -extdirs "" OldCode.java

-source 1.7オプションにより、OldCode.javaのコンパイルにはリリース1.7(または7)のJavaプログラミング言語が使用されます。-target 1.7オプションにより、JVM 1.7と互換性のあるクラス・ファイルが生成されます。

-bootclasspathオプションを使用して、正しいバージョンのブートストラップ・クラス(rt.jarライブラリ)を指定する必要があります。指定しなかった場合は、コンパイラによって次の警告が生成されます。

javac -source 1.7 OldCode.java
warning: [options] bootstrap class path not set in conjunction with -source 1.7

正しいバージョンのブートストラップ・クラスを指定しない場合、コンパイラは新しいブートストラップ・クラスと組み合わせて古い言語規則を使用します。この組合わせにより、存在しないメソッドへの参照が含まれる可能性があるため、クラス・ファイルが古いプラットフォーム(この例ではJava SE 7)で動作しなくなることがあります。この例で、コンパイラはリリース1.7のJavaプログラミング言語を使用します。

• java(1)

• jdb(1)

• javah(1)

• javadoc(1)

• jar(1)

• jdb(1)