このページは Cloud Translation API によって翻訳されました。

Java ルール

ルール

java_binary
java_import
java_library
java_lite_proto_library
java_proto_library
java_test
java_package_configuration
java_plugin
java_runtime
java_ツールチェーン

java_binary

java_binary(name, deps, srcs, data, resources, args, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, output_licenses, plugins, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)

Java アーカイブ（「jar ファイル」）をビルドし、さらにルールと同じ名前のラッパーシェルスクリプトを作成します。ラッパーシェルスクリプトはクラスパスを使用します。特に、バイナリが依存する各ライブラリの JAR ファイルが含まれます。

ラッパースクリプトは、複数の一意のフラグを受け入れます。ラッパーで受け入れられる構成可能なフラグと環境変数のリストについては、//src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt をご覧ください。

暗黙的な出力ターゲット

name.jar: Java アーカイブ。バイナリの直接依存関係に対応するクラスファイルなどのリソースが含まれます。
name-src.jar: ソース（ソース jar）を含むアーカイブ。
name_deploy.jar: デプロイに適した Java アーカイブ（明示的にリクエストされた場合にのみビルドされます）。
ルールの <name>_deploy.jar ターゲットをビルドすると、マニフェストを使用して自己完結型の jar ファイルが作成され、マニフェストには java -jar コマンドまたはラッパースクリプトの --singlejar オプションを指定して実行できるようになります。ラッパースクリプトは、JVM フラグとネイティブライブラリを読み込むオプションも渡すため、java -jar よりも推奨されます。

デプロイ JAR には、バイナリのラッパースクリプトから最初から最後までクラスパスを検索したクラスローダーによって検出されるすべてのクラスが含まれます。また、依存関係に必要なネイティブライブラリも含まれています。これらは実行時に JVM に自動的に読み込まれます。

ターゲットで launcher 属性を指定すると、_deploy.jar は通常の JAR ファイルではなくネイティブバイナリになります。これには、ランチャーと、ルールのネイティブ（C++）依存関係がすべて静的バイナリにリンクされます。実際の jar ファイルのバイトは、そのネイティブバイナリに付加され、実行可能ファイルと Java コードの両方を含む単一のバイナリ blob が作成されます。生成された jar ファイルは、ネイティブバイナリを実行するのと同じように直接実行できます。
name_deploy-src.jar: ターゲットの推移的なクロージャから収集されたソースを含むアーカイブ。条件は、deploy.jar 内のクラスと一致します（ただし、jar に一致するソース jar がない場合を除く）。

deps 属性は、srcs がない java_binary ルールでは許可されません。このようなルールには、runtime_deps が提供する main_class が必要です。

次のコードスニペットは、よくある間違いを示しています。

java_binary(
    name = "DontDoThis",
    srcs = [
        ...,
        "GeneratedJavaFile.java",  # a generated .java file
    ],
    deps = [":generating_rule",],  # rule that generates that file
)

その場合は次のようにしてください。

java_binary(
    name = "DoThisInstead",
    srcs = [
        ...,
        ":generating_rule",
    ],
)

引数

属性
`name`	`Name; required` このターゲットの一意の名前。アプリケーションのメインエントリポイントであるソースファイルの名前（拡張子は除く）を使用することをおすすめします。たとえば、エントリポイントの名前が `Main.java` の場合、名前は `Main` になります。
`deps`	`List of labels; optional` ターゲットにリンクする他のライブラリのリスト。`deps` に関する一般的なコメントについては、ほとんどのビルドルールで定義されている一般的な属性をご覧ください。
`srcs`	`List of labels; optional` ターゲットを作成するために処理されるソースファイルのリスト。この属性はほとんどの場合必須です。下の例外を参照してください。 `.java` 型のソースファイルがコンパイルされます。生成される `.java` ファイルの場合、通常は、ファイル名自体ではなく、生成ルールの名前をここに入力することをおすすめします。これにより、読みやすさが向上するだけでなく、将来の変更に対するルールの復元力が高まります。つまり、将来的に、生成ルールが異なるファイルを生成する場合でも、修正する必要があるのは、生成ルールの `outs` の 1 つのみです。NoOps であるため、生成ルールを `deps` にリストしないでください。 `.srcjar` タイプのソースファイルは解凍され、コンパイルされます。（これは、genrule を使用して一連の `.java` ファイルを生成する必要がある場合に役立ちます）。ルール: ルール（通常は `genrule` または `filegroup`）によって上記のファイルが生成された場合、ソースファイルの場合と同じ方法が使用されます。この引数は、`main_class` 属性がランタイムクラスパスでクラスを指定するか、`runtime_deps` 引数を指定する場合を除き、ほとんどの場合必須です。
`resources`	`List of labels; optional` Java jar に含めるデータファイルのリスト。リソースを指定すると、コンパイルによって生成される通常の `.class` ファイルとともに jar にバンドルされます。jar ファイル内のリソースの場所はプロジェクト構造によって決まります。Bazel はまず、Maven の標準ディレクトリレイアウト（「src」ディレクトリの後ろに「resources」ディレクトリの孫）を探します。これが見つからない場合、Bazel は「java」または「javatests」という最上位ディレクトリを探します（たとえば、リソースが `<workspace root>/x/java/y/java/z` の場合、リソースのパスは `y/java/z` になります）。このヒューリスティックをオーバーライドすることはできません。ただし、`resource_strip_prefix` 属性を使用すると、リソースファイルに特定の代替ディレクトリを指定できます。リソースにはソースファイルと生成ファイルがあります。
`classpath_resources`	`List of labels; optional` 他の方法はないので、このオプションは使用しないでください） Java ツリーのルートに配置する必要があるリソースのリスト。この属性は、クラスパスでリソースを `"myconfig.xml"` として正確に検出する必要があるサードパーティライブラリをサポートすることのみを目的としています。名前空間の競合の危険性があるため、ライブラリでのみ許可され、ライブラリでは許可されません。
`create_executable`	`Boolean; optional; nonconfigurable; default is True` バイナリが実行可能かどうかを示します。非実行可能バイナリは、Java 依存関係の推移を deploy jar に収集しますが、直接実行することはできません。この属性が設定されている場合、ラッパースクリプトは作成されません。`launcher` 属性または `main_class` 属性が設定されていると、0 に設定するとエラーが発生します。
`deploy_env`	`List of labels; optional` このバイナリのデプロイ環境を表す他の `java_binary` ターゲットのリスト。別の `java_binary` で読み込まれるプラグインをビルドするときに、この属性を設定します。この属性を設定すると、このバイナリと `deploy_env` で指定されたターゲットの間で共有されるバイナリのランタイムクラスパス（およびデプロイ jar）からのすべての依存関係が除外されます。
`deploy_manifest_lines`	`List of strings; optional` `*_deploy.jar` ターゲット用に生成された `META-INF/manifest.mf` ファイルに追加する行のリスト。この属性の内容は「変数」の作成の対象にはなりません。
`javacopts`	`List of strings; optional` このライブラリ用の追加のコンパイラオプション。「変数を作成」置換とボーンシェルトークン化が適用されます。これらのコンパイラオプションは、グローバルコンパイラオプションの後に javac に渡されます。
`jvm_flags`	`List of strings; optional` このバイナリの実行用に生成されたラッパースクリプトに埋め込むフラグのリスト。$(location) と「Make 変数」の置換、およびBourne シェルのトークン化が適用されます。 Java バイナリのラッパースクリプトは、CLASSPATH 定義（依存するすべての jar を見つけるため）を含み、適切な Java インタープリタを呼び出します。ラッパースクリプトで生成されるコマンドラインには、メインクラスの名前の後に `"$@"` が続くので、クラス名の後に他の引数を渡すことができます。ただし、JVM による解析を目的とした引数は、コマンドラインでクラス名の前に指定する必要があります。`jvm_flags` の内容は、クラス名が表示される前にラッパースクリプトに追加されます。この属性は、`*_deploy.jar` の出力には影響しません。
`launcher`	`Label; optional` JDK に含まれている通常の `bin/java` プログラムではなく、Java プログラムの実行に使用されるバイナリを指定します。ターゲットは `cc_binary` にする必要があります。 Java Invocation API を実装する `cc_binary` はすべて、この属性の値として指定できます。 Bazel は、デフォルトで通常の JDK ランチャー（bin/java または java.exe）を使用します。関連する `--java_launcher` Bazel フラグは、`launcher` 属性が指定されていないターゲットの `java_binary` ターゲットと `java_test` ターゲットにのみ影響します。ネイティブ（C++、SWIG、JNI）依存関係のビルド方法は、JDK ランチャーと他のランチャーのどちらを使用しているかによって異なります。通常の JDK ランチャー（デフォルト）を使用している場合、ネイティブ依存関係は `{name}_nativedeps.so` という名前の共有ライブラリとしてビルドされます。ここで、`{name}` はこの java_binary ルールの `name` 属性です。この構成の場合、使用されていないコードがリンカーによって削除されることはありません。他のランチャーを使用している場合、ネイティブ（C++）依存関係は、`{name}_nativedeps` という名前のバイナリに静的にリンクされます。ここで、`{name}` はこの java_binary ルールの `name` 属性です。この場合、リンカーは未使用のバイナリを生成されるバイナリから削除します。つまり、`cc_library` ターゲットが `alwayslink = 1` を指定しない限り、JNI 経由でのみアクセスされる C++ コードはリンクされない可能性があります。デフォルトの JDK ランチャー以外のランチャーを使用した場合、`*_deploy.jar` 出力の形式が変更されます。詳細については、メインの java_binary ドキュメントをご覧ください。
`main_class`	`String; optional` エントリポイントとして使用する `main()` メソッドを含むクラスの名前。ルールでこのオプションを使用する場合は、`srcs=[...]` リストは必要ありません。そのため、この属性を使用すると、すでに 1 つ以上の `main()` メソッドを含む Java ライブラリから実行可能ファイルを作成できます。この属性の値はクラス名で、ソースファイルではありません。このクラスは、実行時に利用可能でなければなりません。このルールで（`srcs` から）コンパイルすることも、直接的または推移的な依存関係（`runtime_deps` または `deps`）を通じて提供することもできます。クラスが使用できない場合、バイナリは実行時に失敗します。ビルド時チェックは行われません。
`plugins`	`List of labels; optional` コンパイル時に実行する Java コンパイラプラグイン。この属性で指定されたすべての `java_plugin` は、このルールが作成されるたびに実行されます。ライブラリは、`exported_plugins` を使用する依存関係からプラグインを継承することもできます。プラグインによって生成されたリソースは、このルールの結果として生成される jar に含まれます。
`resource_jars`	`List of labels; optional` 非推奨: 代わりに java_import と deps または runtime_deps を使用してください。
`resource_strip_prefix`	`String; optional` Java リソースから削除するためのパス接頭辞。指定すると、このパス接頭辞は `resources` 属性内のすべてのファイルから削除されます。リソースファイルがこのディレクトリの下にないとエラーが発生します。指定しない場合（デフォルト）、リソースファイルのパスは、ソースファイルの Java パッケージと同じロジックに従って決定されます。たとえば、`stuff/java/foo/bar/a.txt` のソースファイルは `foo/bar/a.txt` にあります。
`runtime_deps`	`List of labels; optional` 最終バイナリで使用できるようにするライブラリ、またはランタイム時のみテストするライブラリ。これらは通常の `deps` と同様にランタイムクラスパスに表示されますが、コンパイル時のクラスパスには表示されません。ランタイム時にのみ必要な依存関係をここに記載する必要があります。依存関係分析ツールは、`runtime_deps` と `deps` の両方に表示されるターゲットを無視する必要があります。
`stamp`	`Integer; optional; default is -1` ビルド情報をバイナリにエンコードするかどうか。考えられる値は次のとおりです。 `stamp = 1`: `--nostamp` ビルドの場合でも、ビルド情報を常にバイナリにスタンプします。この設定は避けてください。この設定により、バイナリおよびそれに依存するすべてのダウンストリームアクションのリモートキャッシュが強制終了される可能性があるためです。 `stamp = 0`: ビルド情報を常に定数値に置き換えます。これにより、ビルド結果を適切にキャッシュに保存できます。 `stamp = -1`: ビルド情報の埋め込みは、`--[no]stamp` フラグで制御されます。スタンプされたバイナリは、依存関係が変更されない限り、再ビルドされません。
`use_launcher`	`Boolean; optional; default is True` バイナリでカスタムランチャーを使用する必要があるかどうか。この属性を false に設定すると、target 属性と、関連する `--java_launcher` フラグはこのターゲットで無視されます。
`use_testrunner`	`Boolean; optional; default is False` テストランナー（デフォルトでは `com.google.testing.junit.runner.BazelTestRunner`）クラスを Java プログラムのメインのエントリポイントとして使用し、`bazel.test_suite` システムプロパティの値としてテストランナーに提供します。これを使用して、デフォルトの動作をオーバーライドできます。つまり、`java_test` ルールのテストランナーを使用し、`java_binary` ルールには使用しないでください。このような操作はあまり必要ありません。1 つの用途は、たとえばテストを実行する前にデータベースをセットアップする場合など、別のルールによって呼び出される `AllTest` ルールです。`AllTest` ルールは `java_binary` として宣言する必要がありますが、テストランナーをメインエントリポイントとして使用する必要があります。テストランナークラスの名前は `main_class` 属性でオーバーライドできます。

java_import

ルールのソースを表示

java_import(name, deps, data, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, visibility)

このルールでは、java_library ルールと java_binary ルールのライブラリとしてプリコンパイルされた .jar ファイルを使用できます。

例

    java_import(
        name = "maven_model",
        jars = [
            "maven_model/maven-aether-provider-3.2.3.jar",
            "maven_model/maven-model-3.2.3.jar",
            "maven_model/maven-model-builder-3.2.3.jar",
        ],
    )

引数

属性
`name`	`Name; required` このターゲットの一意の名前。
`deps`	`List of labels; optional` ターゲットにリンクする他のライブラリのリスト。java_library.deps をご覧ください。
`constraints`	`List of strings; optional; nonconfigurable` このルールに Java ライブラリとして適用される追加の制約。
`exports`	`List of labels; optional` このルールのユーザーが利用できるターゲット。java_library.exports をご覧ください。
`jars`	`List of labels; required` このターゲットに依存する Java ターゲットに提供されている JAR ファイルのリスト。
`neverlink`	`Boolean; optional; default is False` このライブラリはコンパイルにのみ使用してください。実行時には使用されません。実行中にランタイム環境によってライブラリが提供される場合に役立ちます。このようなライブラリの例としては、IDE プラグイン用の IDE API や、標準の JDK で実行されるすべてのもののための `tools.jar` があります。
`proguard_specs`	`List of labels; optional` Proguard 仕様として使用するファイル。これらは、Proguard で使用される仕様のセットを記述します。指定すると、このライブラリに応じて任意の `android_binary` ターゲットに追加されます。ここに含めるファイルには、べき等ルール（-dontnote、-dontwarn、前提条件なし、-keep で始まるルール）のみを含める必要があります。他のオプションは、非自律的なマージを確保するために、`android_binary` の proguard_specs でのみ表示できます。
`runtime_deps`	`List of labels; optional` 最終バイナリで使用できるようにするライブラリ、またはランタイム時のみテストするライブラリ。 java_library.runtime_deps をご覧ください。
`srcjar`	`Label; optional` コンパイルされた JAR ファイルのソースコードを含む JAR ファイル。

java_library

ルールのソースを表示

java_library(name, deps, srcs, data, resources, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javacopts, licenses, neverlink, plugins, proguard_specs, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, visibility)

このルールは、ソースをコンパイルして .jar ファイルにリンクします。

暗黙的な出力ターゲット

libname.jar: クラスファイルを含む Java アーカイブ。
libname-src.jar: ソース（ソース jar）を含むアーカイブ。

引数

属性
`name`	`Name; required` このターゲットの一意の名前。
`deps`	`List of labels; optional` このライブラリにリンクするライブラリのリスト。`deps` に関する一般的なコメントについては、ほとんどのビルドルールで定義されている一般的な属性をご覧ください。 `deps` にリストされている `java_library` ルールによってビルドされた jar は、このルールのコンパイル時のクラスパスになります。さらに、`deps`、`runtime_deps`、`exports` の推移的なクロージャは、ランタイムクラスパスになります。一方、`data` 属性内のターゲットは実行ファイルに含まれますが、コンパイル時クラスとランタイムクラスパスの両方は含まれません。
`srcs`	`List of labels; optional` ターゲットを作成するために処理されるソースファイルのリスト。この属性はほとんどの場合必須です。下の例外を参照してください。 `.java` 型のソースファイルがコンパイルされます。生成される `.java` ファイルの場合、通常は、ファイル名自体ではなく、生成ルールの名前をここに入力することをおすすめします。これにより、読みやすさが向上するだけでなく、将来の変更に対するルールの復元力が高まります。つまり、将来的に、生成ルールが異なるファイルを生成する場合でも、修正する必要があるのは、生成ルールの `outs` の 1 つのみです。NoOps であるため、生成ルールを `deps` にリストしないでください。 `.srcjar` タイプのソースファイルは解凍され、コンパイルされます。（これは、genrule を使用して一連の `.java` ファイルを生成する必要がある場合に役立ちます）。ルール: ルール（通常は `genrule` または `filegroup`）によって上記のファイルが生成された場合、ソースファイルの場合と同じ方法が使用されます。この引数は、`main_class` 属性がランタイムクラスパスでクラスを指定するか、`runtime_deps` 引数を指定する場合を除き、ほとんどの場合必須です。
`data`	`List of labels; optional` 実行時にこのライブラリが必要とするファイルのリスト。`data` に関する一般的なコメントについては、ほとんどのビルドルールで定義されている一般的な属性をご覧ください。 Bazel は、`java_library` をビルドする際、これらのファイルを任意の場所に保存しません。`data` ファイルが生成されると、Bazel によって生成されます。この `java_library` に依存するテストをビルドする場合、Bazel は `data` ファイルをランファイル領域にコピーまたはリンクします。
`resources`	`List of labels; optional` Java jar に含めるデータファイルのリスト。リソースを指定すると、コンパイルによって生成される通常の `.class` ファイルとともに jar にバンドルされます。jar ファイル内のリソースの場所はプロジェクト構造によって決まります。Bazel はまず、Maven の標準ディレクトリレイアウト（「src」ディレクトリの後ろに「resources」ディレクトリの孫）を探します。これが見つからない場合、Bazel は「java」または「javatests」という最上位ディレクトリを探します（たとえば、リソースが `<workspace root>/x/java/y/java/z` の場合、リソースのパスは `y/java/z` になります）。このヒューリスティックをオーバーライドすることはできません。ただし、`resource_strip_prefix` 属性を使用すると、リソースファイルに特定の代替ディレクトリを指定できます。リソースにはソースファイルと生成ファイルがあります。
`exported_plugins`	`List of labels; optional` このライブラリに直接依存するライブラリにエクスポートする `java_plugin`（アノテーションプロセッサなど）のリスト。指定した `java_plugin` のリストは、`plugins` でライブラリが明示的に宣言したように、このライブラリに直接依存するライブラリに適用されます。
`exports`	`List of labels; optional` エクスポートされたライブラリ。ここにルールを一覧表示すると、親がこれらのルールに明示的に依存しているかのように、ルールを親ルールで使用できるようになります。これは、通常の（エクスポートされていない）`deps` には適用されません。要約: `deps` エッジで 0 個以上の `exports` エッジが続く依存関係パスがルール間に存在する場合、ルール X で Y 内のコードにアクセスできます。いくつか例を見てみましょう。 A が B に依存し、B が C に依存していると仮定します。この場合、C は A の推移的な依存関係であるため、C のソースを変更して A を再構築すると、すべてが正しく再ビルドされます。ただし、C では A がクラスを使用できなくなります。これを行うには、A が `deps` で C を宣言するか、B の `exports` 属性で C を宣言することで、A（および A に依存するもの）を簡単に使用できるようにします。エクスポートされたライブラリの閉鎖は、すべての直接の親ルールで行うことができます。少し異なる例を考えてみましょう。A が B に依存し、B が C と D に依存し、C もエクスポートしますが D はエクスポートしません。これで、A は C にはアクセスできますが、D にはアクセスできません。今、C と D がそれぞれ C' と D' のライブラリをエクスポートした場合、A は C' にのみアクセスでき、D' にはアクセスできません。重要: エクスポートされたルールは、通常の依存関係ではありません。上記の例では、B が C をエクスポートして C も使用したい場合は、それを独自の `deps` にリストする必要もあります。
`javacopts`	`List of strings; optional` このライブラリ用の追加のコンパイラオプション。「変数を作成」置換とボーンシェルトークン化が適用されます。これらのコンパイラオプションは、グローバルコンパイラオプションの後に javac に渡されます。
`neverlink`	`Boolean; optional; default is False` このライブラリをコンパイルにのみ使用し、ランタイムでは使用しません。実行時にランタイム環境からライブラリが提供される場合に役立ちます。このようなライブラリの例としては、IDE プラグイン用の IDE API や、標準の JDK で実行されるもの用の `tools.jar` があります。 `neverlink = 1` により、Java 言語仕様（例:`String` またはプリミティブ型の `static final` 定数）。したがって、ランタイムライブラリがコンパイルライブラリと同一である場合に推奨されるユースケースがあります。ランタイムライブラリがコンパイルライブラリと異なる場合は、JLS でコンパイラがインライン化できない場所（および今後のすべての JLS のバージョンで保持する必要がある場所）でのみ異なるようにする必要があります。
`plugins`	`List of labels; optional` コンパイル時に実行する Java コンパイラプラグイン。この属性で指定されたすべての `java_plugin` は、このルールが作成されるたびに実行されます。ライブラリは、`exported_plugins` を使用する依存関係からプラグインを継承することもできます。プラグインによって生成されたリソースは、このルールの結果として生成される jar に含まれます。
`proguard_specs`	`List of labels; optional` Proguard 仕様として使用するファイル。これらは、Proguard で使用される仕様のセットを記述します。指定すると、このライブラリに応じて任意の `android_binary` ターゲットに追加されます。ここに含めるファイルには、べき等ルール（-dontnote、-dontwarn、前提条件なし、-keep で始まるルール）のみを含める必要があります。他のオプションは、非自律的なマージを確保するために、`android_binary` の proguard_specs でのみ表示できます。
`resource_jars`	`List of labels; optional` 非推奨: 代わりに java_import と deps または runtime_deps を使用してください。
`resource_strip_prefix`	`String; optional` Java リソースから削除するためのパス接頭辞。指定すると、このパス接頭辞は `resources` 属性内のすべてのファイルから削除されます。リソースファイルがこのディレクトリの下にないとエラーが発生します。指定しない場合（デフォルト）、リソースファイルのパスは、ソースファイルの Java パッケージと同じロジックに従って決定されます。たとえば、`stuff/java/foo/bar/a.txt` のソースファイルは `foo/bar/a.txt` にあります。
`runtime_deps`	`List of labels; optional` 最終バイナリで使用できるようにするライブラリ、またはランタイム時のみテストするライブラリ。これらは通常の `deps` と同様にランタイムクラスパスに表示されますが、コンパイル時のクラスパスには表示されません。ランタイム時にのみ必要な依存関係をここに記載する必要があります。依存関係分析ツールは、`runtime_deps` と `deps` の両方に表示されるターゲットを無視する必要があります。

java_lite_proto_library

ルールのソースを表示

java_lite_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

java_lite_proto_library は、.proto ファイルから Java コードを生成します。

deps は proto_library ルールを指す必要があります。

例:

java_library(
    name = "lib",
    deps = [":foo"],
)

java_lite_proto_library(
    name = "foo",
    deps = [":bar"],
)

proto_library(
    name = "bar",
)

引数

属性

name

Name; required

このターゲットの一意の名前。

deps

List of labels; optional

Java コードを生成する proto_library ルールのリスト。

java_proto_library

ルールのソースを表示

java_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

java_proto_library は、.proto ファイルから Java コードを生成します。

deps は proto_library ルールを指す必要があります。

例:

java_library(
    name = "lib",
    deps = [":foo_java_proto"],
)

java_proto_library(
    name = "foo_java_proto",
    deps = [":foo_proto"],
)

proto_library(
    name = "foo_proto",
)

引数

属性

name

Name; required

このターゲットの一意の名前。

deps

List of labels; optional

Java コードを生成する proto_library ルールのリスト。

java_test

ルールのソースを表示

java_test(name, deps, srcs, data, resources, args, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, plugins, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)

java_test() ルールは Java テストをコンパイルします。テストは、テストコードを囲むバイナリラッパーです。テストランナーのメインメソッドは、コンパイルされるメインクラスではなく、呼び出されます。

暗黙的な出力ターゲット

name.jar: Java アーカイブ。
name_deploy.jar: デプロイに適した Java アーカイブ。（明示的にリクエストされた場合のみビルドされます）。詳しくは、java_binary からの name_deploy.jar 出力の説明をご覧ください。

java_binary() 引数に関するセクションをご覧ください。このルールは、すべてのテストルール（*_test）に共通するすべての属性もサポートしています。

例

java_library(
    name = "tests",
    srcs = glob(["*.java"]),
    deps = [
        "//java/com/foo/base:testResources",
        "//java/com/foo/testing/util",
    ],
)

java_test(
    name = "AllTests",
    size = "small",
    runtime_deps = [
        ":tests",
        "//util/mysql",
    ],
)

引数

属性
`name`	`Name; required` このターゲットの一意の名前。
`deps`	`List of labels; optional` ターゲットにリンクする他のライブラリのリスト。`deps` に関する一般的なコメントについては、ほとんどのビルドルールで定義されている一般的な属性をご覧ください。
`srcs`	`List of labels; optional` ターゲットを作成するために処理されるソースファイルのリスト。この属性はほとんどの場合必須です。下の例外を参照してください。 `.java` 型のソースファイルがコンパイルされます。生成される `.java` ファイルの場合、通常は、ファイル名自体ではなく、生成ルールの名前をここに入力することをおすすめします。これにより、読みやすさが向上するだけでなく、将来の変更に対するルールの復元力が高まります。つまり、将来的に、生成ルールが異なるファイルを生成する場合でも、修正する必要があるのは、生成ルールの `outs` の 1 つのみです。NoOps であるため、生成ルールを `deps` にリストしないでください。 `.srcjar` タイプのソースファイルは解凍され、コンパイルされます。（これは、genrule を使用して一連の `.java` ファイルを生成する必要がある場合に役立ちます）。ルール: ルール（通常は `genrule` または `filegroup`）によって上記のファイルが生成された場合、ソースファイルの場合と同じ方法が使用されます。この引数は、`main_class` 属性がランタイムクラスパスでクラスを指定するか、`runtime_deps` 引数を指定する場合を除き、ほとんどの場合必須です。
`resources`	`List of labels; optional` Java jar に含めるデータファイルのリスト。リソースを指定すると、コンパイルによって生成される通常の `.class` ファイルとともに jar にバンドルされます。jar ファイル内のリソースの場所はプロジェクト構造によって決まります。Bazel はまず、Maven の標準ディレクトリレイアウト（「src」ディレクトリの後ろに「resources」ディレクトリの孫）を探します。これが見つからない場合、Bazel は「java」または「javatests」という最上位ディレクトリを探します（たとえば、リソースが `<workspace root>/x/java/y/java/z` の場合、リソースのパスは `y/java/z` になります）。このヒューリスティックをオーバーライドすることはできません。ただし、`resource_strip_prefix` 属性を使用すると、リソースファイルに特定の代替ディレクトリを指定できます。リソースにはソースファイルと生成ファイルがあります。
`classpath_resources`	`List of labels; optional` 他の方法はないので、このオプションは使用しないでください） Java ツリーのルートに配置する必要があるリソースのリスト。この属性は、クラスパスでリソースを `"myconfig.xml"` として正確に検出する必要があるサードパーティライブラリをサポートすることのみを目的としています。名前空間の競合の危険性があるため、ライブラリでのみ許可され、ライブラリでは許可されません。
`create_executable`	`Boolean; optional; nonconfigurable; default is True` バイナリが実行可能かどうかを示します。非実行可能バイナリは、Java 依存関係の推移を deploy jar に収集しますが、直接実行することはできません。この属性が設定されている場合、ラッパースクリプトは作成されません。`launcher` 属性または `main_class` 属性が設定されていると、0 に設定するとエラーが発生します。
`deploy_manifest_lines`	`List of strings; optional` `*_deploy.jar` ターゲット用に生成された `META-INF/manifest.mf` ファイルに追加する行のリスト。この属性の内容は「変数」の作成の対象にはなりません。
`javacopts`	`List of strings; optional` このライブラリ用の追加のコンパイラオプション。「変数を作成」置換とボーンシェルトークン化が適用されます。これらのコンパイラオプションは、グローバルコンパイラオプションの後に javac に渡されます。
`jvm_flags`	`List of strings; optional` このバイナリの実行用に生成されたラッパースクリプトに埋め込むフラグのリスト。$(location) と「Make 変数」の置換、およびBourne シェルのトークン化が適用されます。 Java バイナリのラッパースクリプトは、CLASSPATH 定義（依存するすべての jar を見つけるため）を含み、適切な Java インタープリタを呼び出します。ラッパースクリプトで生成されるコマンドラインには、メインクラスの名前の後に `"$@"` が続くので、クラス名の後に他の引数を渡すことができます。ただし、JVM による解析を目的とした引数は、コマンドラインでクラス名の前に指定する必要があります。`jvm_flags` の内容は、クラス名が表示される前にラッパースクリプトに追加されます。この属性は、`*_deploy.jar` の出力には影響しません。
`launcher`	`Label; optional` JDK に含まれている通常の `bin/java` プログラムではなく、Java プログラムの実行に使用されるバイナリを指定します。ターゲットは `cc_binary` にする必要があります。 Java Invocation API を実装する `cc_binary` はすべて、この属性の値として指定できます。 Bazel は、デフォルトで通常の JDK ランチャー（bin/java または java.exe）を使用します。関連する `--java_launcher` Bazel フラグは、`launcher` 属性が指定されていないターゲットの `java_binary` ターゲットと `java_test` ターゲットにのみ影響します。ネイティブ（C++、SWIG、JNI）依存関係のビルド方法は、JDK ランチャーと他のランチャーのどちらを使用しているかによって異なります。通常の JDK ランチャー（デフォルト）を使用している場合、ネイティブ依存関係は `{name}_nativedeps.so` という名前の共有ライブラリとしてビルドされます。ここで、`{name}` はこの java_binary ルールの `name` 属性です。この構成の場合、使用されていないコードがリンカーによって削除されることはありません。他のランチャーを使用している場合、ネイティブ（C++）依存関係は、`{name}_nativedeps` という名前のバイナリに静的にリンクされます。ここで、`{name}` はこの java_binary ルールの `name` 属性です。この場合、リンカーは未使用のバイナリを生成されるバイナリから削除します。つまり、`cc_library` ターゲットが `alwayslink = 1` を指定しない限り、JNI 経由でのみアクセスされる C++ コードはリンクされない可能性があります。デフォルトの JDK ランチャー以外のランチャーを使用した場合、`*_deploy.jar` 出力の形式が変更されます。詳細については、メインの java_binary ドキュメントをご覧ください。
`main_class`	`String; optional` エントリポイントとして使用する `main()` メソッドを含むクラスの名前。ルールでこのオプションを使用する場合は、`srcs=[...]` リストは必要ありません。そのため、この属性を使用すると、すでに 1 つ以上の `main()` メソッドを含む Java ライブラリから実行可能ファイルを作成できます。この属性の値はクラス名で、ソースファイルではありません。このクラスは、実行時に利用可能でなければなりません。このルールで（`srcs` から）コンパイルすることも、直接的または推移的な依存関係（`runtime_deps` または `deps`）を通じて提供することもできます。クラスが使用できない場合、バイナリは実行時に失敗します。ビルド時チェックは行われません。
`plugins`	`List of labels; optional` コンパイル時に実行する Java コンパイラプラグイン。この属性で指定されたすべての `java_plugin` は、このルールが作成されるたびに実行されます。ライブラリは、`exported_plugins` を使用する依存関係からプラグインを継承することもできます。プラグインによって生成されたリソースは、このルールの結果として生成される jar に含まれます。
`resource_jars`	`List of labels; optional` 非推奨: 代わりに java_import と deps または runtime_deps を使用してください。
`resource_strip_prefix`	`String; optional` Java リソースから削除するためのパス接頭辞。指定すると、このパス接頭辞は `resources` 属性内のすべてのファイルから削除されます。リソースファイルがこのディレクトリの下にないとエラーが発生します。指定しない場合（デフォルト）、リソースファイルのパスは、ソースファイルの Java パッケージと同じロジックに従って決定されます。たとえば、`stuff/java/foo/bar/a.txt` のソースファイルは `foo/bar/a.txt` にあります。
`runtime_deps`	`List of labels; optional` 最終バイナリで使用できるようにするライブラリ、またはランタイム時のみテストするライブラリ。これらは通常の `deps` と同様にランタイムクラスパスに表示されますが、コンパイル時のクラスパスには表示されません。ランタイム時にのみ必要な依存関係をここに記載する必要があります。依存関係分析ツールは、`runtime_deps` と `deps` の両方に表示されるターゲットを無視する必要があります。
`stamp`	`Integer; optional; default is 0` ビルド情報をバイナリにエンコードするかどうか。考えられる値は次のとおりです。 `stamp = 1`: `--nostamp` ビルドの場合でも、ビルド情報を常にバイナリにスタンプします。この設定は避けてください。この設定により、バイナリおよびそれに依存するすべてのダウンストリームアクションのリモートキャッシュが強制終了される可能性があるためです。 `stamp = 0`: ビルド情報を常に定数値に置き換えます。これにより、ビルド結果を適切にキャッシュに保存できます。 `stamp = -1`: ビルド情報の埋め込みは、`--[no]stamp` フラグで制御されます。スタンプされたバイナリは、依存関係が変更されない限り、再ビルドされません。
`test_class`	`String; optional` テストランナーによって読み込まれる Java クラス。デフォルトでは、この引数が定義されていない場合、以前のモードが使用され、代わりにテスト引数が使用されます。最初の引数でフォールバックしないように `--nolegacy_bazel_java_test` フラグを設定します。この属性では、このテストで実行する Java クラスの名前を指定します。これが必要になることはまれです。この引数を省略すると、ターゲットの `name` とそのソースルート相対パスを使用して推測されます。テストが既知のソースルートの外部に配置されている場合、`test_class` が設定されていない場合、Bazel はエラーを報告します。 JUnit3 の場合、テストクラスは `junit.framework.TestCase` のサブクラスであるか、`junit.framework.Test` を返すパブリック静的 `suite()` メソッド（または `Test` のサブクラス）である必要があります。JUnit4 の場合、クラスには `org.junit.runner.RunWith` アノテーションを付ける必要があります。この属性を使用して、複数の `java_test` ルールで同じ `Test`（`TestCase`、`TestSuite`、...）を共有できます。通常、追加情報は（`jvm_flags=['-Dkey=value']` を介して）渡されるため、テストの異なるサブセットの実行など、動作が異なります。この属性を使用すると、`javatests` ツリーの外部で Java テストを使用することもできます。
`use_launcher`	`Boolean; optional; default is True` バイナリでカスタムランチャーを使用する必要があるかどうか。この属性を false に設定すると、target 属性と、関連する `--java_launcher` フラグはこのターゲットで無視されます。
`use_testrunner`	`Boolean; optional; default is True` テストランナー（デフォルトでは `com.google.testing.junit.runner.BazelTestRunner`）クラスを Java プログラムのメインのエントリポイントとして使用し、`bazel.test_suite` システムプロパティの値としてテストランナーに提供します。これを使用して、デフォルトの動作をオーバーライドできます。つまり、`java_test` ルールのテストランナーを使用し、`java_binary` ルールには使用しないでください。このような操作はあまり必要ありません。1 つの用途は、たとえばテストを実行する前にデータベースをセットアップする場合など、別のルールによって呼び出される `AllTest` ルールです。`AllTest` ルールは `java_binary` として宣言する必要がありますが、テストランナーをメインエントリポイントとして使用する必要があります。テストランナークラスの名前は `main_class` 属性でオーバーライドできます。

java_package_configuration

ルールのソースを表示

java_package_configuration(name, data, compatible_with, deprecation, distribs, features, javacopts, licenses, packages, restricted_to, tags, target_compatible_with, testonly, visibility)

一連のパッケージに適用する構成。構成は java_toolchain.javacopts に追加できます。

例:

java_package_configuration(
    name = "my_configuration",
    packages = [":my_packages"],
    javacopts = ["-Werror"],
)

package_group(
    name = "my_packages",
    packages = [
        "//com/my/project/...",
        "-//com/my/project/testing/...",
    ],
)

java_toolchain(
    ...,
    package_configuration = [
        ":my_configuration",
    ]
)

引数

属性
`name`	`Name; required` このターゲットの一意の名前。
`data`	`List of labels; optional` 実行時にこの構成で必要なファイルのリスト。
`javacopts`	`List of strings; optional` Java コンパイラフラグ。
`packages`	`List of labels; optional` 構成を適用する `package_group` のセット。

java_plugin

ルールのソースを表示

java_plugin(name, deps, srcs, data, resources, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_jars, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, visibility)

java_plugin は、Bazel で実行される Java コンパイラのプラグインを定義します。現在、サポートされているプラグインのタイプはアノテーションプロセッサのみです。java_library ルールまたは java_binary ルールでは、plugins 属性によってプラグインに依存できます。java_library は、exported_plugins を使用して、プラグインに直接依存するライブラリに自動的にプラグインをエクスポートすることもできます。

暗黙的な出力ターゲット

libname.jar: Java アーカイブ。

引数は、processor_class 引数が追加された点を除き、java_library と同じです。

引数

属性
`name`	`Name; required` このターゲットの一意の名前。
`deps`	`List of labels; optional` このライブラリにリンクするライブラリのリスト。`deps` に関する一般的なコメントについては、ほとんどのビルドルールで定義されている一般的な属性をご覧ください。 `deps` にリストされている `java_library` ルールによってビルドされた jar は、このルールのコンパイル時のクラスパスになります。さらに、`deps`、`runtime_deps`、`exports` の推移的なクロージャは、ランタイムクラスパスになります。一方、`data` 属性内のターゲットは実行ファイルに含まれますが、コンパイル時クラスとランタイムクラスパスの両方は含まれません。
`srcs`	`List of labels; optional` ターゲットを作成するために処理されるソースファイルのリスト。この属性はほとんどの場合必須です。下の例外を参照してください。 `.java` 型のソースファイルがコンパイルされます。生成される `.java` ファイルの場合、通常は、ファイル名自体ではなく、生成ルールの名前をここに入力することをおすすめします。これにより、読みやすさが向上するだけでなく、将来の変更に対するルールの復元力が高まります。つまり、将来的に、生成ルールが異なるファイルを生成する場合でも、修正する必要があるのは、生成ルールの `outs` の 1 つのみです。NoOps であるため、生成ルールを `deps` にリストしないでください。 `.srcjar` タイプのソースファイルは解凍され、コンパイルされます。（これは、genrule を使用して一連の `.java` ファイルを生成する必要がある場合に役立ちます）。ルール: ルール（通常は `genrule` または `filegroup`）によって上記のファイルが生成された場合、ソースファイルの場合と同じ方法が使用されます。この引数は、`main_class` 属性がランタイムクラスパスでクラスを指定するか、`runtime_deps` 引数を指定する場合を除き、ほとんどの場合必須です。
`data`	`List of labels; optional` 実行時にこのライブラリが必要とするファイルのリスト。`data` に関する一般的なコメントについては、ほとんどのビルドルールで定義されている一般的な属性をご覧ください。 Bazel は、`java_library` をビルドする際、これらのファイルを任意の場所に保存しません。`data` ファイルが生成されると、Bazel によって生成されます。この `java_library` に依存するテストをビルドする場合、Bazel は `data` ファイルをランファイル領域にコピーまたはリンクします。
`resources`	`List of labels; optional` Java jar に含めるデータファイルのリスト。リソースを指定すると、コンパイルによって生成される通常の `.class` ファイルとともに jar にバンドルされます。jar ファイル内のリソースの場所はプロジェクト構造によって決まります。Bazel はまず、Maven の標準ディレクトリレイアウト（「src」ディレクトリの後ろに「resources」ディレクトリの孫）を探します。これが見つからない場合、Bazel は「java」または「javatests」という最上位ディレクトリを探します（たとえば、リソースが `<workspace root>/x/java/y/java/z` の場合、リソースのパスは `y/java/z` になります）。このヒューリスティックをオーバーライドすることはできません。ただし、`resource_strip_prefix` 属性を使用すると、リソースファイルに特定の代替ディレクトリを指定できます。リソースにはソースファイルと生成ファイルがあります。
`generates_api`	`Boolean; optional; default is False` この属性は、API コードを生成するアノテーションプロセッサをマークします。ルールで API 生成アノテーションプロセッサを使用している場合、コンパイルアクションが生成ルールの後にスケジュールされている場合にのみ、それに依存する他のルールが生成されたコードを参照できます。この属性は、--java_header_compilation が有効になっている場合に、スケジューリングの制約を導入するように Bazel に指示します。警告: この属性はビルドのパフォーマンスに影響します。この属性は必要な場合にのみ使用してください。
`javacopts`	`List of strings; optional` このライブラリ用の追加のコンパイラオプション。「変数を作成」置換とボーンシェルトークン化が適用されます。これらのコンパイラオプションは、グローバルコンパイラオプションの後に javac に渡されます。
`neverlink`	`Boolean; optional; default is False` このライブラリをコンパイルにのみ使用し、ランタイムでは使用しません。実行時にランタイム環境からライブラリが提供される場合に役立ちます。このようなライブラリの例としては、IDE プラグイン用の IDE API や、標準の JDK で実行されるもの用の `tools.jar` があります。 `neverlink = 1` により、Java 言語仕様（例:`String` またはプリミティブ型の `static final` 定数）。したがって、ランタイムライブラリがコンパイルライブラリと同一である場合に推奨されるユースケースがあります。ランタイムライブラリがコンパイルライブラリと異なる場合は、JLS でコンパイラがインライン化できない場所（および今後のすべての JLS のバージョンで保持する必要がある場所）でのみ異なるようにする必要があります。
`output_licenses`	`Licence type; optional` `common attributes` を参照
`plugins`	`List of labels; optional` コンパイル時に実行する Java コンパイラプラグイン。この属性で指定されたすべての `java_plugin` は、このルールが作成されるたびに実行されます。ライブラリは、`exported_plugins` を使用する依存関係からプラグインを継承することもできます。プラグインによって生成されたリソースは、このルールの結果として生成される jar に含まれます。
`processor_class`	`String; optional` プロセッサクラスは、Java コンパイラがアノテーションプロセッサへのエントリポイントとして使用する必要があるクラスの完全修飾型です。指定しない場合、このルールは Java コンパイラのアノテーション処理にアノテーションプロセッサを提供しませんが、ランタイムのクラスパスはコンパイラのアノテーションプロセッサのパスには含まれます。（これは主に、 java.util.ServiceLoader を使用してアノテーションプロセッサパスから読み込まれる Error Prone プラグインでの使用を想定しています）。
`proguard_specs`	`List of labels; optional` Proguard 仕様として使用するファイル。これらは、Proguard で使用される仕様のセットを記述します。指定すると、このライブラリに応じて任意の `android_binary` ターゲットに追加されます。ここに含めるファイルには、べき等ルール（-dontnote、-dontwarn、前提条件なし、-keep で始まるルール）のみを含める必要があります。他のオプションは、非自律的なマージを確保するために、`android_binary` の proguard_specs でのみ表示できます。
`resource_jars`	`List of labels; optional` 非推奨: 代わりに java_import と deps または runtime_deps を使用してください。
`resource_strip_prefix`	`String; optional` Java リソースから削除するためのパス接頭辞。指定すると、このパス接頭辞は `resources` 属性内のすべてのファイルから削除されます。リソースファイルがこのディレクトリの下にないとエラーが発生します。指定しない場合（デフォルト）、リソースファイルのパスは、ソースファイルの Java パッケージと同じロジックに従って決定されます。たとえば、`stuff/java/foo/bar/a.txt` のソースファイルは `foo/bar/a.txt` にあります。

java_runtime

ルールのソースを表示

java_runtime(name, srcs, compatible_with, default_cds, deprecation, distribs, features, hermetic_srcs, java, java_home, lib_modules, licenses, restricted_to, tags, target_compatible_with, testonly, version, visibility)

Java ランタイムの構成を指定します。

例:

java_runtime(
    name = "jdk-9-ea+153",
    srcs = glob(["jdk9-ea+153/**"]),
    java_home = "jdk9-ea+153",
)

引数

属性
`name`	`Name; required` このターゲットの一意の名前。
`srcs`	`List of labels; optional` ランタイム内のすべてのファイル。
`default_cds`	`Label; optional` 密閉型の `java_runtime` のデフォルトの CDS アーカイブ。`java_binary` ターゲットで密閉が有効な場合、ターゲットが `classlist` 属性を指定して独自の CDS アーカイブを指定しない場合、`java_runtime` のデフォルト CDS は密閉型デプロイ JAR にパッケージ化されます。
`hermetic_srcs`	`List of labels; optional` 密閉型デプロイに必要なランタイム内のファイル。
`java`	`Label; optional` Java 実行可能ファイルのパス。
`java_home`	`String; optional` ランタイムのルートへのパス。「Make」変数の置換が適用されます。このパスが絶対パスの場合、ルールはよく知られたパスを持つ非密閉の Java ランタイムを示します。その場合、`srcs` 属性と `java` 属性は空にする必要があります。
`lib_modules`	`Label; optional` 密閉型デプロイに必要な lib/modules ファイル。
`version`	`Integer; optional; default is 0` Java ランタイムの機能バージョン。つまり、`Runtime.version().feature()` によって返される整数です。

java_ツールチェーン

ルールのソースを表示

java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_with, deprecation, deps_checker, distribs, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_workers, javacopts, jvm_opts, licenses, oneversion, oneversion_whitelist, package_configuration, proguard_allowlister, resourcejar, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, tools, turbine_data, turbine_jvm_opts, visibility, xlint)

Java コンパイラの構成を指定します。使用するツールチェーンは、--java_ツールチェーンの引数を使用して変更できます。Java コンパイラを調整しない限り、通常、この種のルールは作成しないでください。

例

簡単な例を以下に示します。

java_toolchain(
    name = "toolchain",
    source_version = "7",
    target_version = "7",
    bootclasspath = ["//tools/jdk:bootclasspath"],
    xlint = [ "classfile", "divzero", "empty", "options", "path" ],
    javacopts = [ "-g" ],
    javabuilder = ":JavaBuilder_deploy.jar",
)

引数

属性
`name`	`Name; required` このターゲットの一意の名前。
`android_lint_data`	`List of labels; optional` android_lint_jvm_opts でラベルの拡張に利用できるツールのラベル。
`android_lint_jvm_opts`	`List of strings; optional` Android Lint を呼び出すときの JVM の引数のリスト。
`android_lint_opts`	`List of strings; optional` Android Lint 引数のリスト。
`android_lint_package_configuration`	`List of labels; optional` 指定したパッケージグループに適用する必要がある Android lint 構成。
`android_lint_runner`	`Label; optional` Android Lint ランナーのラベル（ある場合）。
`bootclasspath`	`List of labels; optional` Java のターゲット bootclasspath エントリ。javac の -bootclasspath フラグに対応します。
`deps_checker`	`List of labels; optional` ImportDepsChecker デプロイ jar のラベル。
`forcibly_disable_header_compilation`	`Boolean; optional; default is False` --java_header_compilation をオーバーライドして、ヘッダーコンパイルをサポートしていないプラットフォーム（JDK 7 Bazel など）でヘッダーコンパイルを無効にします。
`genclass`	`List of labels; required` GenClass デプロイ jar のラベル。
`header_compiler`	`List of labels; optional` ヘッダーコンパイラのラベル。--java_header_compilation が有効な場合は必須。
`header_compiler_direct`	`List of labels; optional` API 生成のアノテーションプロセッサを含まない直接クラスパスアクションに使用するヘッダーコンパイラのオプションラベル。このツールは、アノテーション処理をサポートしていません。
`ijar`	`List of labels; required` ijar 実行可能ファイルのラベル。
`jacocorunner`	`Label; optional` JacocoCoverageRunner のラベル（jar など）。
`java_runtime`	`Label; required` このツールチェーンで使用する java_runtime。実行構成のデフォルトは java_runtime です。
`javabuilder`	`List of labels; required` JavaBuilder deploy jar のラベル。
`javabuilder_data`	`List of labels; optional` javabuilder_jvm_opts でラベル拡張に使用可能なデータのラベル。
`javabuilder_jvm_opts`	`List of strings; optional` JavaBuilder を起動する際の JVM の引数のリスト。
`javac_supports_multiplex_workers`	`Boolean; optional; default is True` JavaBuilder が Multiplex 永続ワーカーとしての実行をサポートしている場合は true、そうでない場合は false です。
`javac_supports_workers`	`Boolean; optional; default is True` JavaBuilder が永続ワーカーとしての実行をサポートしている場合は true、そうでない場合は false です。
`javacopts`	`List of strings; optional` Java コンパイラの追加引数のリスト。可能性のある Java コンパイラフラグの完全なリストについては、Java コンパイラのドキュメントを参照してください。
`jvm_opts`	`List of strings; optional` Java コンパイラを呼び出す際の JVM の引数のリスト。このオプションで使用できるフラグの一覧については、Java 仮想マシンのドキュメントをご覧ください。
`oneversion`	`Label; optional` 1 バージョンの適用バイナリのラベル。
`oneversion_whitelist`	`Label; optional` 1 つのバージョンの許可リストのラベル。
`package_configuration`	`List of labels; optional` 指定したパッケージグループに適用する設定。
`proguard_allowlister`	`Label; optional; default is @bazel_tools//tools/jdk:proguard_whitelister` Proguard 許可リストのラベル。
`resourcejar`	`List of labels; optional` リソースの jar ビルダー実行可能ファイルのラベル。
`singlejar`	`List of labels; required` SingleJar デプロイ JAR のラベル。
`source_version`	`String; optional` Java ソースバージョン（「6」、「7」など）。Java ソースコードで使用できるコード構造のセットを指定します。
`target_version`	`String; optional` Java のターゲットバージョン（「6」、「7」など）。クラスをどの Java ランタイム用にビルドするかを指定します。
`timezone_data`	`Label; optional` タイムゾーンデータを含むリソース jar のラベル。設定すると、すべての java_binary ルールの暗黙的なランタイム依存関係として、タイムゾーンデータが追加されます。
`tools`	`List of labels; optional` jvm_opts でラベルの展開に使用できるツールのラベル。
`turbine_data`	`List of labels; optional` turbine_jvm_opts でラベル拡張に使用できるデータのラベル。
`turbine_jvm_opts`	`List of strings; optional` タービン呼び出し時の JVM の引数のリスト。
`xlint`	`List of strings; optional` デフォルトのリストから追加または削除する警告のリスト。削除するには、先頭にダッシュを追加します。詳細については、-Xlint オプションに関する Javac のドキュメントをご覧ください。