As inscrições para a BazelCon 2024 já estão abertas.

Esta página foi traduzida pela API Cloud Translation.

Regras do Java

Report an issue View source Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Regras

java_binary
java_import
java_library
java_lite_proto_library
java_proto_library
java_test
java_package_configuration
java_plugin
java_runtime
java_toolchain

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)

Cria um arquivo Java ("arquivo jar") e um script de shell wrapper com o mesmo nome da regra. O script de shell do wrapper usa um classpath que inclui, entre outras coisas, um arquivo JAR para cada biblioteca de que o binário depende. Ao executar o script de shell do wrapper, qualquer variável de ambiente JAVABIN que não esteja vazia terá precedência sobre a versão especificada pela flag --java_runtime_version do Bazel.

O script wrapper aceita várias flags exclusivas. Consulte //src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt para conferir uma lista de flags configuráveis e variáveis de ambiente aceitas pelo wrapper.

Alvos de saída implícitos

name.jar: um arquivo Java que contém os arquivos de classe e outros recursos correspondentes às dependências diretas do binário.
name-src.jar: um arquivo que contém as origens ("jar de origem").
name_deploy.jar: um arquivo Java adequado para implantação (somente criado se solicitado explicitamente).
A criação do destino <name>_deploy.jar para a regra cria um arquivo jar autocontido com um manifesto que permite que ele seja executado com o comando java -jar ou com a opção --singlejar do script de wrapper. O uso do script wrapper é preferido ao java -jar porque ele também transmite as flags da JVM e as opções para carregar bibliotecas nativas.

O jar do deploy contém todas as classes que seriam encontradas por um classloader que pesquisou o classpath do script wrapper do binário do início ao fim. Ele também contém as bibliotecas nativas necessárias para dependências. Eles são carregados automaticamente na JVM no momento da execução.

Se o destino especificar um atributo launcher, o _deploy.jar será um binário nativo, em vez de um arquivo JAR normal. Ele vai conter o iniciador e todas as dependências nativas (C++) da regra, todas vinculadas a um binário estático. Os bytes do arquivo JAR serão anexados a esse binário nativo, criando um blob binário único contendo o executável e o código Java. Você pode executar o arquivo jar resultante diretamente, como faria com qualquer binário nativo.
name_deploy-src.jar: um arquivo que contém as origens coletadas da interseção transitiva do destino. Eles vão corresponder às classes no deploy.jar, exceto quando os JARs não tiverem um JAR de origem correspondente.

Um atributo deps não é permitido em uma regra java_binary sem srcs. Essa regra exige um main_class fornecido por runtime_deps.

O snippet de código a seguir ilustra um erro comum:

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

Faça o seguinte:

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

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação. É recomendável usar o nome do arquivo de origem que é o ponto de entrada principal do aplicativo (menos a extensão). Por exemplo, se o ponto de entrada for chamado `Main.java`, seu nome poderá ser `Main`.
`deps`	Lista de rótulos; o padrão é `[]` A lista de outras bibliotecas que serão vinculadas ao destino. Confira comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build.
`srcs`	Lista de rótulos; o padrão é `[]` A lista de arquivos de origem que são processados para criar o destino. Esse atributo é quase sempre obrigatório. Confira as exceções abaixo. Os arquivos de origem do tipo `.java` são compilados. No caso de arquivos `.java` gerados, geralmente é recomendável colocar o nome da regra geradora aqui em vez do nome do arquivo. Isso não apenas melhora a legibilidade, mas torna a regra mais resistente a mudanças futuras: se a regra de geração gerar arquivos diferentes no futuro, você só precisará corrigir um lugar: o `outs` da regra de geração. Não liste a regra de geração em `deps` porque ela não tem efeito. Os arquivos de origem do tipo `.srcjar` são descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos `.java` com uma genrule. Regras: se a regra (normalmente `genrule` ou `filegroup`) gerar qualquer um dos arquivos listados acima, eles serão usados da mesma forma que os arquivos de origem. Esse argumento quase sempre é necessário, exceto se um atributo `main_class` especificar uma classe no caminho de classe do ambiente de execução ou se você especificar o argumento `runtime_deps`.
`resources`	Lista de rótulos; o padrão é `[]` Uma lista de arquivos de dados a serem incluídos em um JAR do Java. Se os recursos forem especificados, eles serão agrupados no jar com os arquivos `.class` normais produzidos pela compilação. O local dos recursos dentro do arquivo JAR é determinado pela estrutura do projeto. O Bazel procura primeiro o layout de diretório padrão do Maven, um diretório "src" seguido por um diretório filho "resources". Se ele não for encontrado, o Bazel vai procurar o diretório principal chamado "java" ou "javatests". Por exemplo, se um recurso estiver em `<workspace root>/x/java/y/java/z`, o caminho do recurso será `y/java/z`. Essa heurística não pode ser substituída, mas o atributo `resource_strip_prefix` pode ser usado para especificar um diretório alternativo específico para arquivos de recursos. Os recursos podem ser arquivos de origem ou gerados.
`classpath_resources`	Lista de rótulos; o padrão é `[]` NÃO USE ESTA OPÇÃO A MENOS QUE NÃO HAJA OUTRA MANEIRA DE FAZER ISSO) Uma lista de recursos que precisam estar na raiz da árvore Java. O único propósito desse atributo é oferecer suporte a bibliotecas de terceiros que exigem que os recursos sejam encontrados no classpath como exatamente `"myconfig.xml"`. Ela só é permitida em arquivos binários, e não em bibliotecas, devido ao risco de conflitos de namespace.
`create_executable`	Booleano; não configurável; o padrão é `True` obsoleto: use `java_single_jar`.
`deploy_env`	Lista de rótulos; o padrão é `[]` Uma lista de outros destinos `java_binary` que representam o ambiente de implantação para esse binário. Defina esse atributo ao criar um plug-in que será carregado por outro `java_binary`. Definir esse atributo exclui todas as dependências do caminho de classe do ambiente de execução (e do jar de implantação) desse binário que são compartilhadas entre esse binário e os destinos especificados em `deploy_env`.
`deploy_manifest_lines`	Lista de strings. O padrão é `[]`. Uma lista de linhas a serem adicionadas ao arquivo `META-INF/manifest.mf` gerado para o `_deploy.jar`. O conteúdo desse atributo não* está sujeito à substituição "Make variable".
`javacopts`	Lista de strings. O padrão é `[]`. Opções extras do compilador para esta biblioteca. Sujeito à substituição de "Make variable" e tokenização de shell Bourne. Essas opções são transmitidas para o javac depois das opções globais.
`jvm_flags`	Lista de strings. O padrão é `[]`. Uma lista de flags para incorporar no script de wrapper gerado para executar esse binário. Sujeito a $(location) e "Make variable" substituição e tokenização de shell Bourne. O script wrapper para um binário Java inclui uma definição de CLASSPATH (para encontrar todos os jars dependentes) e invoca o interpretador Java correto. A linha de comando gerada pelo script wrapper inclui o nome da classe principal seguido por um `"$@"` para que você possa transmitir outros argumentos após o nome da classe. No entanto, os argumentos destinados à análise pela JVM precisam ser especificados antes do nome da classe na linha de comando. O conteúdo de `jvm_flags` é adicionado ao script wrapper antes que o nome da classe seja listado. Esse atributo não tem efeito nas saídas de `*_deploy.jar`.
`launcher`	Rótulo: o padrão é `None`. Especifique um binário que será usado para executar seu programa Java em vez do programa `bin/java` normal incluído no JDK. O destino precisa ser um `cc_binary`. Qualquer `cc_binary` que implemente a API Java Invocation pode ser especificado como um valor para esse atributo. Por padrão, o Bazel usa o iniciador JDK normal (bin/java ou java.exe). A flag `--java_launcher` do Bazel relacionada afeta apenas os alvos `java_binary` e `java_test` que não especificaram um atributo `launcher`. Suas dependências nativas (C++, SWIG, JNI) serão criadas de maneira diferente dependendo se você está usando o iniciador do JDK ou outro: Se você estiver usando o iniciador JDK normal (padrão), as dependências nativas serão criadas como uma biblioteca compartilhada chamada `{name}_nativedeps.so`, em que `{name}` é o atributo `name` dessa regra java_binary. O código não utilizado não é removido pelo vinculador nessa configuração. Se você estiver usando qualquer outro iniciador, as dependências nativas (C++) serão vinculadas de forma estática a um binário chamado `{name}_nativedeps`, em que `{name}` é o atributo `name` desta regra java_binary. Nesse caso, o vinculador vai remover qualquer código que ele considere não utilizado do binário resultante, o que significa que qualquer código C++ acessado apenas por JNI não poderá ser vinculado, a menos que o destino `cc_library` especifique `alwayslink = 1`. Ao usar qualquer iniciador que não seja o padrão do JDK, o formato da saída `*_deploy.jar` muda. Consulte os documentos principais java_binary para mais detalhes.
`main_class`	String; o padrão é `""` Nome da classe com o método `main()` a ser usado como ponto de entrada. Se uma regra usar essa opção, ela não precisará de uma lista `srcs=[...]`. Assim, com esse atributo, é possível criar um executável de uma biblioteca Java que já contém um ou mais métodos `main()`. O valor desse atributo é um nome de classe, não um arquivo de origem. A classe precisa estar disponível no momento da execução: ela pode ser compilada por essa regra (do `srcs`) ou fornecida por dependências diretas ou transitivas (por `runtime_deps` ou `deps`). Se a classe não estiver disponível, o binário vai falhar no momento da execução. Não há verificação no momento da criação.
`plugins`	Lista de rótulos; o padrão é `[]` Plug-ins de compilador Java para execução no tempo de compilação. Cada `java_plugin` especificado neste atributo será executado sempre que essa regra for criada. Uma biblioteca também pode herdar plug-ins de dependências que usam `exported_plugins`. Os recursos gerados pelo plug-in serão incluídos no jar resultante dessa regra.
`resource_jars`	Lista de rótulos; o padrão é `[]` Descontinuado: use java_import e deps ou runtime_deps.
`resource_strip_prefix`	String; o padrão é `""` O prefixo do caminho a ser removido dos recursos Java. Se especificado, esse prefixo de caminho é removido de todos os arquivos no atributo `resources`. É um erro um arquivo de recurso não estar nesse diretório. Se não for especificado (padrão), o caminho do arquivo de recurso será determinado de acordo com a mesma lógica do pacote Java de arquivos de origem. Por exemplo, um arquivo de origem em `stuff/java/foo/bar/a.txt` será localizado em `foo/bar/a.txt`.
`runtime_deps`	Lista de rótulos; o padrão é `[]` Bibliotecas para disponibilizar ao binário final ou testar apenas no momento da execução. Como o `deps` comum, elas vão aparecer no caminho de classe de execução, mas, ao contrário delas, não no caminho de classe de tempo de compilação. As dependências necessárias apenas no tempo de execução precisam ser listadas aqui. As ferramentas de análise de dependência precisam ignorar os destinos que aparecem em `runtime_deps` e `deps`.
`stamp`	Inteiro; padrão é `-1` Define se as informações de build serão codificadas no binário. Valores possíveis: `stamp = 1`: sempre carimbe as informações do build no binário, mesmo em `--nostamp`. Evite essa configuração, porque ela pode interromper o armazenamento em cache remoto do binário e de qualquer ação downstream que dependa dele. `stamp = 0`: sempre substitua as informações de build por valores constantes. Isso gera um bom cache de resultados de build. `stamp = -1`: a incorporação de informações de build é controlada pela flag `--[no]stamp`. Os binários carimbados não são reconstruídos, a menos que as dependências mudem.
`use_launcher`	Booleano; o padrão é `True` Indica se o binário precisa usar um iniciador personalizado. Se esse atributo for definido como falso, o atributo launcher e a flag `--java_launcher` serão ignorados para esse destino.
`use_testrunner`	Booleano; o padrão é `False` Use a classe executora de testes (`com.google.testing.junit.runner.BazelTestRunner`, por padrão) como o ponto de entrada principal de um programa Java e forneça a classe de teste ao executor de testes como um valor da propriedade do sistema `bazel.test_suite`. Você pode usar isso para substituir o comportamento padrão, que é usar o executor de testes para regras `java_test`, e não para regras `java_binary`. É improvável que você queira fazer isso. Um uso é para regras `AllTest` que são invocadas por outra regra (para configurar um banco de dados antes de executar os testes, por exemplo). A regra `AllTest` precisa ser declarada como um `java_binary`, mas ainda precisa usar o executor de teste como ponto de entrada principal. O nome de uma classe de executor de teste pode ser substituído pelo atributo `main_class`.

java_import

Acessar a origem da regra

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)

Essa regra permite o uso de arquivos .jar pré-compilados como bibliotecas para regras java_library e java_binary.

Exemplos

    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",
        ],
    )

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`deps`	Lista de rótulos; o padrão é `[]` A lista de outras bibliotecas que serão vinculadas ao destino. Consulte java_library.deps.
`constraints`	Lista de strings não configuráveis; o padrão é `[]` Restrições extras impostas a essa regra como uma biblioteca Java.
`exports`	Lista de rótulos; o padrão é `[]` Destinatários que serão disponibilizados aos usuários dessa regra. Consulte java_library.exports.
`jars`	Lista de rótulos; obrigatório A lista de arquivos JAR fornecidos para destinos Java que dependem desse destino.
`neverlink`	Booleano; o padrão é `False` Use essa biblioteca apenas para compilação, e não no momento da execução. Útil se a biblioteca for fornecida pelo ambiente de execução durante a execução. Exemplos de bibliotecas como essa são APIs de ambiente de desenvolvimento integrado para plug-ins de ambiente de desenvolvimento integrado ou `tools.jar` para qualquer coisa executada em um JDK padrão.
`proguard_specs`	Lista de rótulos; o padrão é `[]` Arquivos a serem usados como especificação do Proguard. Eles descrevem o conjunto de especificações que serão usados pelo Proguard. Se especificado, eles serão adicionados a qualquer destino `android_binary` que dependa dessa biblioteca. Os arquivos incluídos aqui precisam ter apenas regras idempotentes, ou seja, -dontnote, -dontwarn, assumenosideeffects e regras que começam com -keep. Outras opções só podem aparecer em proguard_specs de `android_binary` para garantir mesclagens não tautológicas.
`runtime_deps`	Lista de rótulos; o padrão é `[]` Bibliotecas para disponibilizar ao binário final ou testar apenas no momento da execução. Consulte java_library.runtime_deps.
`srcjar`	Rótulo: o padrão é `None`. Um arquivo JAR que contém o código-fonte dos arquivos JAR compilados.

java_library

Acessar a origem da regra

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)

Essa regra compila e vincula origens a um arquivo .jar.

Alvos de saída implícitos

libname.jar: um arquivo Java que contém os arquivos de classe.
libname-src.jar: um arquivo que contém as origens ("jar de origem").

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`deps`	Lista de rótulos; o padrão é `[]` A lista de bibliotecas a serem vinculadas a essa biblioteca. Confira comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build. Os jars criados pelas regras `java_library` listados em `deps` vão estar no caminho de classe de tempo de compilação desta regra. Além disso, o fechamento transitivo de `deps`, `runtime_deps` e `exports` estará no caminho de classe do ambiente de execução. Por outro lado, os destinos no atributo `data` são incluídos nos arquivos de execução, mas não no caminho de classe de tempo de execução nem de compilação.
`srcs`	Lista de rótulos; o padrão é `[]` A lista de arquivos de origem que são processados para criar o destino. Esse atributo é quase sempre obrigatório. Confira as exceções abaixo. Os arquivos de origem do tipo `.java` são compilados. No caso de arquivos `.java` gerados, geralmente é recomendável colocar o nome da regra geradora aqui em vez do nome do arquivo. Isso não apenas melhora a legibilidade, mas torna a regra mais resistente a mudanças futuras: se a regra de geração gerar arquivos diferentes no futuro, você só precisará corrigir um lugar: o `outs` da regra de geração. Não liste a regra de geração em `deps` porque ela não tem efeito. Os arquivos de origem do tipo `.srcjar` são descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos `.java` com uma genrule. Regras: se a regra (normalmente `genrule` ou `filegroup`) gerar qualquer um dos arquivos listados acima, eles serão usados da mesma forma que os arquivos de origem. Esse argumento quase sempre é necessário, exceto se um atributo `main_class` especificar uma classe no caminho de classe do ambiente de execução ou se você especificar o argumento `runtime_deps`.
`data`	Lista de rótulos; o padrão é `[]` A lista de arquivos necessários para essa biblioteca no momento da execução. Confira comentários gerais sobre `data` em Atributos típicos definidos pela maioria das regras de build. Ao criar um `java_library`, o Bazel não coloca esses arquivos em nenhum lugar. Se os arquivos `data` forem arquivos gerados, o Bazel os gerará. Ao criar um teste que depende desse `java_library`, o Bazel copia ou vincula os arquivos `data` à área de arquivos de execução.
`resources`	Lista de rótulos; o padrão é `[]` Uma lista de arquivos de dados a serem incluídos em um JAR do Java. Se os recursos forem especificados, eles serão agrupados no jar com os arquivos `.class` normais produzidos pela compilação. O local dos recursos dentro do arquivo JAR é determinado pela estrutura do projeto. O Bazel procura primeiro o layout de diretório padrão do Maven, um diretório "src" seguido por um diretório filho "resources". Se ele não for encontrado, o Bazel vai procurar o diretório principal chamado "java" ou "javatests". Por exemplo, se um recurso estiver em `<workspace root>/x/java/y/java/z`, o caminho do recurso será `y/java/z`. Essa heurística não pode ser substituída, mas o atributo `resource_strip_prefix` pode ser usado para especificar um diretório alternativo específico para arquivos de recursos. Os recursos podem ser arquivos de origem ou gerados.
`exported_plugins`	Lista de rótulos; o padrão é `[]` A lista de `java_plugin`s (por exemplo, processadores de anotações) a serem exportadas para bibliotecas que dependem diretamente dessa biblioteca. A lista especificada de `java_plugin`s será aplicada a qualquer biblioteca que dependa diretamente dela, como se ela tivesse declarado explicitamente esses rótulos em `plugins`.
`exports`	Lista de rótulos; o padrão é `[]` Bibliotecas exportadas. Listar regras aqui as disponibiliza para as regras mãe, como se elas dependessem explicitamente delas. Isso não é verdade para `deps`s normais (não exportados). Resumo: uma regra X pode acessar o código em Y se houver um caminho de dependência entre eles que comece com uma aresta `deps` seguida por zero ou mais arestas `exports`. Vamos conferir alguns exemplos para ilustrar isso. Suponha que A dependa de B e B dependa de C. Nesse caso, C é uma dependência transitiva de A. Portanto, mudar as origens de C e recriar A vai recriar tudo corretamente. No entanto, A não poderá usar classes em C. Para permitir isso, A precisa declarar C no `deps`, ou B pode facilitar para A (e qualquer coisa que possa depender de A) declarando C no atributo `exports` de B. O fechamento das bibliotecas exportadas está disponível para todas as regras principais diretas. Considere um exemplo um pouco diferente: A depende de B, B depende de C e D e também exporta C, mas não D. Agora, A tem acesso a C, mas não a D. Agora, se C e D exportaram algumas bibliotecas, C' e D', respectivamente, A só pode acessar C', mas não D'. Importante: uma regra exportada não é uma dependência regular. No exemplo anterior, se B exporta C e quer usar C, ele também precisa listar C no próprio `deps`.
`javacopts`	Lista de strings. O padrão é `[]`. Opções extras do compilador para esta biblioteca. Sujeito à substituição de "Make variable" e tokenização de shell Bourne. Essas opções são transmitidas para o javac depois das opções globais.
`neverlink`	Booleano; o padrão é `False` Indica se essa biblioteca precisa ser usada apenas para compilação e não no momento da execução. Útil se a biblioteca for fornecida pelo ambiente de execução durante a execução. Exemplos dessas bibliotecas são as APIs do ambiente de desenvolvimento integrado para plug-ins do ambiente de desenvolvimento integrado ou `tools.jar` para qualquer coisa executada em um JDK padrão. `neverlink = 1` não impede que o compilador insira o material dessa biblioteca em destinos de compilação que dependem dela, conforme permitido pela especificação da linguagem Java (por exemplo, constantes `static final` de `String` ou de tipos primitivos). O caso de uso preferencial é quando a biblioteca de execução é idêntica à biblioteca de compilação. Se a biblioteca de tempo de execução for diferente da biblioteca de compilação, ela vai ser diferente apenas nos locais em que o JLS proíbe que os compiladores sejam inline (e isso precisa ser mantido para todas as versões futuras do JLS).
`plugins`	Lista de rótulos; o padrão é `[]` Plug-ins de compilador Java para execução no tempo de compilação. Cada `java_plugin` especificado neste atributo será executado sempre que essa regra for criada. Uma biblioteca também pode herdar plug-ins de dependências que usam `exported_plugins`. Os recursos gerados pelo plug-in serão incluídos no jar resultante dessa regra.
`proguard_specs`	Lista de rótulos; o padrão é `[]` Arquivos a serem usados como especificação do Proguard. Eles descrevem o conjunto de especificações que serão usados pelo Proguard. Se especificado, eles serão adicionados a qualquer destino `android_binary` que dependa dessa biblioteca. Os arquivos incluídos aqui precisam ter apenas regras idempotentes, ou seja, -dontnote, -dontwarn, assumenosideeffects e regras que começam com -keep. Outras opções só podem aparecer em proguard_specs de `android_binary` para garantir mesclagens não tautológicas.
`resource_jars`	Lista de rótulos; o padrão é `[]` Descontinuado: use java_import e deps ou runtime_deps.
`resource_strip_prefix`	String; o padrão é `""` O prefixo do caminho a ser removido dos recursos Java. Se especificado, esse prefixo de caminho é removido de todos os arquivos no atributo `resources`. É um erro um arquivo de recurso não estar nesse diretório. Se não for especificado (padrão), o caminho do arquivo de recurso será determinado de acordo com a mesma lógica do pacote Java de arquivos de origem. Por exemplo, um arquivo de origem em `stuff/java/foo/bar/a.txt` será localizado em `foo/bar/a.txt`.
`runtime_deps`	Lista de rótulos; o padrão é `[]` Bibliotecas para disponibilizar ao binário final ou testar apenas no momento da execução. Como o `deps` comum, elas vão aparecer no caminho de classe de execução, mas, ao contrário delas, não no caminho de classe de tempo de compilação. As dependências necessárias apenas no tempo de execução precisam ser listadas aqui. As ferramentas de análise de dependência precisam ignorar os destinos que aparecem em `runtime_deps` e `deps`.

java_lite_proto_library

Acessar a origem da regra

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 gera código Java de arquivos .proto.

deps precisa apontar para regras proto_library.

Exemplo:

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

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

proto_library(
    name = "bar",
)

Argumentos

Atributos

name

Nome: obrigatório

Um nome exclusivo para essa segmentação.

deps

Lista de rótulos; o padrão é []

A lista de regras proto_library para gerar código Java.

java_proto_library

Acessar a origem da regra

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 gera código Java de arquivos .proto.

deps precisa apontar para regras proto_library.

Exemplo:

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

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

proto_library(
    name = "foo_proto",
)

Argumentos

Atributos

name

Nome: obrigatório

Um nome exclusivo para essa segmentação.

deps

Lista de rótulos; o padrão é []

A lista de regras proto_library para gerar código Java.

java_test

Acessar a origem da regra

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)

Uma regra java_test() compila um teste Java. Um teste é um wrapper binário em torno do código de teste. O método principal do executor de teste é invocado em vez da classe principal que está sendo compilada.

Alvos de saída implícitos

name.jar: um arquivo Java.
name_deploy.jar: um arquivo Java adequado para implantação. (Somente criado se solicitado explicitamente.) Consulte a descrição da saída name_deploy.jar de java_binary para mais detalhes.

Consulte a seção sobre argumentos java_binary(). Essa regra também aceita todos os atributos comuns a todas as regras de teste (*_test).

Exemplos

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",
    ],
)

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`deps`	Lista de rótulos; o padrão é `[]` A lista de outras bibliotecas que serão vinculadas ao destino. Confira comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build.
`srcs`	Lista de rótulos; o padrão é `[]` A lista de arquivos de origem que são processados para criar o destino. Esse atributo é quase sempre obrigatório. Confira as exceções abaixo. Os arquivos de origem do tipo `.java` são compilados. No caso de arquivos `.java` gerados, geralmente é recomendável colocar o nome da regra geradora aqui em vez do nome do arquivo. Isso não apenas melhora a legibilidade, mas torna a regra mais resistente a mudanças futuras: se a regra de geração gerar arquivos diferentes no futuro, você só precisará corrigir um lugar: o `outs` da regra de geração. Não liste a regra de geração em `deps` porque ela não tem efeito. Os arquivos de origem do tipo `.srcjar` são descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos `.java` com uma genrule. Regras: se a regra (normalmente `genrule` ou `filegroup`) gerar qualquer um dos arquivos listados acima, eles serão usados da mesma forma que os arquivos de origem. Esse argumento quase sempre é necessário, exceto se um atributo `main_class` especificar uma classe no caminho de classe do ambiente de execução ou se você especificar o argumento `runtime_deps`.
`resources`	Lista de rótulos; o padrão é `[]` Uma lista de arquivos de dados a serem incluídos em um JAR do Java. Se os recursos forem especificados, eles serão agrupados no jar com os arquivos `.class` normais produzidos pela compilação. O local dos recursos dentro do arquivo JAR é determinado pela estrutura do projeto. O Bazel procura primeiro o layout de diretório padrão do Maven, um diretório "src" seguido por um diretório filho "resources". Se ele não for encontrado, o Bazel vai procurar o diretório principal chamado "java" ou "javatests". Por exemplo, se um recurso estiver em `<workspace root>/x/java/y/java/z`, o caminho do recurso será `y/java/z`. Essa heurística não pode ser substituída, mas o atributo `resource_strip_prefix` pode ser usado para especificar um diretório alternativo específico para arquivos de recursos. Os recursos podem ser arquivos de origem ou gerados.
`classpath_resources`	Lista de rótulos; o padrão é `[]` NÃO USE ESTA OPÇÃO A MENOS QUE NÃO HAJA OUTRA MANEIRA DE FAZER ISSO) Uma lista de recursos que precisam estar na raiz da árvore Java. O único propósito desse atributo é oferecer suporte a bibliotecas de terceiros que exigem que os recursos sejam encontrados no classpath como exatamente `"myconfig.xml"`. Ela só é permitida em arquivos binários, e não em bibliotecas, devido ao risco de conflitos de namespace.
`create_executable`	Booleano; não configurável; o padrão é `True` obsoleto: use `java_single_jar`.
`deploy_manifest_lines`	Lista de strings. O padrão é `[]`. Uma lista de linhas a serem adicionadas ao arquivo `META-INF/manifest.mf` gerado para o `_deploy.jar`. O conteúdo desse atributo não* está sujeito à substituição "Make variable".
`javacopts`	Lista de strings. O padrão é `[]`. Opções extras do compilador para esta biblioteca. Sujeito à substituição de "Make variable" e tokenização de shell Bourne. Essas opções são transmitidas para o javac depois das opções globais.
`jvm_flags`	Lista de strings. O padrão é `[]`. Uma lista de flags para incorporar no script de wrapper gerado para executar esse binário. Sujeito a $(location) e "Make variable" substituição e tokenização de shell Bourne. O script wrapper para um binário Java inclui uma definição de CLASSPATH (para encontrar todos os jars dependentes) e invoca o interpretador Java correto. A linha de comando gerada pelo script wrapper inclui o nome da classe principal seguido por um `"$@"` para que você possa transmitir outros argumentos após o nome da classe. No entanto, os argumentos destinados à análise pela JVM precisam ser especificados antes do nome da classe na linha de comando. O conteúdo de `jvm_flags` é adicionado ao script wrapper antes que o nome da classe seja listado. Esse atributo não tem efeito nas saídas de `*_deploy.jar`.
`launcher`	Rótulo: o padrão é `None`. Especifique um binário que será usado para executar seu programa Java em vez do programa `bin/java` normal incluído no JDK. O destino precisa ser um `cc_binary`. Qualquer `cc_binary` que implemente a API Java Invocation pode ser especificado como um valor para esse atributo. Por padrão, o Bazel usa o iniciador JDK normal (bin/java ou java.exe). A flag `--java_launcher` do Bazel relacionada afeta apenas os alvos `java_binary` e `java_test` que não especificaram um atributo `launcher`. Suas dependências nativas (C++, SWIG, JNI) serão criadas de maneira diferente dependendo se você está usando o iniciador do JDK ou outro: Se você estiver usando o iniciador JDK normal (padrão), as dependências nativas serão criadas como uma biblioteca compartilhada chamada `{name}_nativedeps.so`, em que `{name}` é o atributo `name` dessa regra java_binary. O código não utilizado não é removido pelo vinculador nessa configuração. Se você estiver usando qualquer outro iniciador, as dependências nativas (C++) serão vinculadas de forma estática a um binário chamado `{name}_nativedeps`, em que `{name}` é o atributo `name` desta regra java_binary. Nesse caso, o vinculador vai remover qualquer código que ele considere não utilizado do binário resultante, o que significa que qualquer código C++ acessado apenas por JNI não poderá ser vinculado, a menos que o destino `cc_library` especifique `alwayslink = 1`. Ao usar qualquer iniciador que não seja o padrão do JDK, o formato da saída `*_deploy.jar` muda. Consulte os documentos principais java_binary para mais detalhes.
`main_class`	String; o padrão é `""` Nome da classe com o método `main()` a ser usado como ponto de entrada. Se uma regra usar essa opção, ela não precisará de uma lista `srcs=[...]`. Assim, com esse atributo, é possível criar um executável de uma biblioteca Java que já contém um ou mais métodos `main()`. O valor desse atributo é um nome de classe, não um arquivo de origem. A classe precisa estar disponível no momento da execução: ela pode ser compilada por essa regra (do `srcs`) ou fornecida por dependências diretas ou transitivas (por `runtime_deps` ou `deps`). Se a classe não estiver disponível, o binário vai falhar no momento da execução. Não há verificação no momento da criação.
`plugins`	Lista de rótulos; o padrão é `[]` Plug-ins de compilador Java para execução no tempo de compilação. Cada `java_plugin` especificado neste atributo será executado sempre que essa regra for criada. Uma biblioteca também pode herdar plug-ins de dependências que usam `exported_plugins`. Os recursos gerados pelo plug-in serão incluídos no jar resultante dessa regra.
`resource_jars`	Lista de rótulos; o padrão é `[]` Descontinuado: use java_import e deps ou runtime_deps.
`resource_strip_prefix`	String; o padrão é `""` O prefixo do caminho a ser removido dos recursos Java. Se especificado, esse prefixo de caminho é removido de todos os arquivos no atributo `resources`. É um erro um arquivo de recurso não estar nesse diretório. Se não for especificado (padrão), o caminho do arquivo de recurso será determinado de acordo com a mesma lógica do pacote Java de arquivos de origem. Por exemplo, um arquivo de origem em `stuff/java/foo/bar/a.txt` será localizado em `foo/bar/a.txt`.
`runtime_deps`	Lista de rótulos; o padrão é `[]` Bibliotecas para disponibilizar ao binário final ou testar apenas no momento da execução. Como o `deps` comum, elas vão aparecer no caminho de classe de execução, mas, ao contrário delas, não no caminho de classe de tempo de compilação. As dependências necessárias apenas no tempo de execução precisam ser listadas aqui. As ferramentas de análise de dependência precisam ignorar os destinos que aparecem em `runtime_deps` e `deps`.
`stamp`	Inteiro; padrão é `0` Define se as informações de build serão codificadas no binário. Valores possíveis: `stamp = 1`: sempre carimbe as informações do build no binário, mesmo em `--nostamp`. Evite essa configuração, porque ela pode interromper o armazenamento em cache remoto do binário e de qualquer ação downstream que dependa dele. `stamp = 0`: sempre substitua as informações de build por valores constantes. Isso gera um bom cache de resultados de build. `stamp = -1`: a incorporação de informações de build é controlada pela flag `--[no]stamp`. Os binários carimbados não são reconstruídos, a menos que as dependências mudem.
`test_class`	String; o padrão é `""` A classe Java que será carregada pelo executor de testes. Por padrão, se esse argumento não for definido, o modo legado será usado e os argumentos de teste serão usados. Defina a flag `--nolegacy_bazel_java_test` para não usar o primeiro argumento. Esse atributo especifica o nome de uma classe Java a ser executada por esse teste. É raro precisar definir isso. Se esse argumento for omitido, ele será inferido usando o `name` do destino e o caminho relativo à raiz da origem. Se o teste estiver localizado fora de uma raiz de origem conhecida, o Bazel vai informar um erro se `test_class` não estiver definido. No JUnit3, a classe de teste precisa ser uma subclasse de `junit.framework.TestCase` ou ter um método `suite()` estático público que retorne um `junit.framework.Test` (ou uma subclasse de `Test`). No JUnit4, a classe precisa ser anotada com `org.junit.runner.RunWith`. Esse atributo permite que várias regras `java_test` compartilhem o mesmo `Test` (`TestCase`, `TestSuite`, ...). Normalmente, outras informações são transmitidas a ele (por exemplo, via `jvm_flags=['-Dkey=value']`) para que o comportamento seja diferente em cada caso, como executar um subconjunto diferente dos testes. Esse atributo também permite o uso de testes Java fora da árvore `javatests`.
`use_launcher`	Booleano; o padrão é `True` Indica se o binário precisa usar um iniciador personalizado. Se esse atributo for definido como falso, o atributo launcher e a flag `--java_launcher` serão ignorados para esse destino.
`use_testrunner`	Booleano; o padrão é `True` Use a classe executora de testes (`com.google.testing.junit.runner.BazelTestRunner`, por padrão) como o ponto de entrada principal de um programa Java e forneça a classe de teste ao executor de testes como um valor da propriedade do sistema `bazel.test_suite`. Você pode usar isso para substituir o comportamento padrão, que é usar o executor de testes para regras `java_test`, e não para regras `java_binary`. É improvável que você queira fazer isso. Um uso é para regras `AllTest` que são invocadas por outra regra (para configurar um banco de dados antes de executar os testes, por exemplo). A regra `AllTest` precisa ser declarada como um `java_binary`, mas ainda precisa usar o executor de teste como ponto de entrada principal. O nome de uma classe de executor de teste pode ser substituído pelo atributo `main_class`.

java_package_configuration

Acessar a origem da regra

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

Configuração a ser aplicada a um conjunto de pacotes. As configurações podem ser adicionadas a java_toolchain.javacoptss.

Exemplo:

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",
    ]
)

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`data`	Lista de rótulos; o padrão é `[]` A lista de arquivos necessários para essa configuração no momento da execução.
`javacopts`	Lista de strings. O padrão é `[]`. Flags do compilador Java.
`packages`	Lista de rótulos; o padrão é `[]` O conjunto de `package_group`s em que a configuração precisa ser aplicada.

java_plugin

Acessar a origem da regra

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 define plug-ins para o compilador Java executado pelo Bazel. No momento, os únicos tipos de plug-ins compatíveis são processadores de anotações. Uma regra java_library ou java_binary pode executar plug-ins dependendo deles pelo atributo plugins. Um java_library também pode exportar automaticamente plug-ins para bibliotecas que dependem diretamente dele usando exported_plugins.

Alvos de saída implícitos

libname.jar: um arquivo Java.

Os argumentos são idênticos a java_library, exceto pela adição do argumento processor_class.

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`deps`	Lista de rótulos; o padrão é `[]` A lista de bibliotecas a serem vinculadas a essa biblioteca. Confira comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build. Os jars criados pelas regras `java_library` listados em `deps` vão estar no caminho de classe de tempo de compilação desta regra. Além disso, o fechamento transitivo de `deps`, `runtime_deps` e `exports` estará no caminho de classe do ambiente de execução. Por outro lado, os destinos no atributo `data` são incluídos nos arquivos de execução, mas não no caminho de classe de tempo de execução nem de compilação.
`srcs`	Lista de rótulos; o padrão é `[]` A lista de arquivos de origem que são processados para criar o destino. Esse atributo é quase sempre obrigatório. Confira as exceções abaixo. Os arquivos de origem do tipo `.java` são compilados. No caso de arquivos `.java` gerados, geralmente é recomendável colocar o nome da regra geradora aqui em vez do nome do arquivo. Isso não apenas melhora a legibilidade, mas torna a regra mais resistente a mudanças futuras: se a regra de geração gerar arquivos diferentes no futuro, você só precisará corrigir um lugar: o `outs` da regra de geração. Não liste a regra de geração em `deps` porque ela não tem efeito. Os arquivos de origem do tipo `.srcjar` são descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos `.java` com uma genrule. Regras: se a regra (normalmente `genrule` ou `filegroup`) gerar qualquer um dos arquivos listados acima, eles serão usados da mesma forma que os arquivos de origem. Esse argumento quase sempre é necessário, exceto se um atributo `main_class` especificar uma classe no caminho de classe do ambiente de execução ou se você especificar o argumento `runtime_deps`.
`data`	Lista de rótulos; o padrão é `[]` A lista de arquivos necessários para essa biblioteca no momento da execução. Confira comentários gerais sobre `data` em Atributos típicos definidos pela maioria das regras de build. Ao criar um `java_library`, o Bazel não coloca esses arquivos em nenhum lugar. Se os arquivos `data` forem arquivos gerados, o Bazel os gerará. Ao criar um teste que depende desse `java_library`, o Bazel copia ou vincula os arquivos `data` à área de arquivos de execução.
`resources`	Lista de rótulos; o padrão é `[]` Uma lista de arquivos de dados a serem incluídos em um JAR do Java. Se os recursos forem especificados, eles serão agrupados no jar com os arquivos `.class` normais produzidos pela compilação. O local dos recursos dentro do arquivo JAR é determinado pela estrutura do projeto. O Bazel procura primeiro o layout de diretório padrão do Maven, um diretório "src" seguido por um diretório filho "resources". Se ele não for encontrado, o Bazel vai procurar o diretório principal chamado "java" ou "javatests". Por exemplo, se um recurso estiver em `<workspace root>/x/java/y/java/z`, o caminho do recurso será `y/java/z`. Essa heurística não pode ser substituída, mas o atributo `resource_strip_prefix` pode ser usado para especificar um diretório alternativo específico para arquivos de recursos. Os recursos podem ser arquivos de origem ou gerados.
`generates_api`	Booleano; o padrão é `False` Esse atributo marca processadores de anotação que geram código de API. Se uma regra usa um processador de anotação que gera uma API, outras regras que dependem dela só podem se referir ao código gerado se as ações de compilação forem programadas após a regra de geração. Esse atributo instrui o Bazel a introduzir restrições de programação quando --java_header_compilation estiver ativado. AVISO: esse atributo afeta o desempenho do build. Use-o apenas se necessário.
`javacopts`	Lista de strings. O padrão é `[]`. Opções extras do compilador para esta biblioteca. Sujeito à substituição de "Make variable" e tokenização de shell Bourne. Essas opções são transmitidas para o javac depois das opções globais.
`neverlink`	Booleano; o padrão é `False` Indica se essa biblioteca precisa ser usada apenas para compilação e não no momento da execução. Útil se a biblioteca for fornecida pelo ambiente de execução durante a execução. Exemplos dessas bibliotecas são as APIs do ambiente de desenvolvimento integrado para plug-ins do ambiente de desenvolvimento integrado ou `tools.jar` para qualquer coisa executada em um JDK padrão. `neverlink = 1` não impede que o compilador insira o material dessa biblioteca em destinos de compilação que dependem dela, conforme permitido pela especificação da linguagem Java (por exemplo, constantes `static final` de `String` ou de tipos primitivos). O caso de uso preferencial é quando a biblioteca de execução é idêntica à biblioteca de compilação. Se a biblioteca de tempo de execução for diferente da biblioteca de compilação, ela vai ser diferente apenas nos locais em que o JLS proíbe que os compiladores sejam inline (e isso precisa ser mantido para todas as versões futuras do JLS).
`output_licenses`	Tipo de licença. O padrão é `["none"]`. Consulte `common attributes`.
`plugins`	Lista de rótulos; o padrão é `[]` Plug-ins de compilador Java para execução no tempo de compilação. Cada `java_plugin` especificado neste atributo será executado sempre que essa regra for criada. Uma biblioteca também pode herdar plug-ins de dependências que usam `exported_plugins`. Os recursos gerados pelo plug-in serão incluídos no jar resultante dessa regra.
`processor_class`	String; o padrão é `""` A classe do processador é o tipo totalmente qualificado da classe que o compilador Java precisa usar como ponto de entrada para o processador de anotações. Se não for especificada, essa regra não vai contribuir com um processador de anotações para o processamento de anotações do compilador Java, mas o caminho de classe de execução ainda será incluído no caminho do processador de anotações do compilador. Essa finalidade é principalmente para uso por plug-ins com maior probabilidade de erros, que são carregados do caminho do processador de anotações usando java.util.ServiceLoader.
`proguard_specs`	Lista de rótulos; o padrão é `[]` Arquivos a serem usados como especificação do Proguard. Eles descrevem o conjunto de especificações que serão usados pelo Proguard. Se especificado, eles serão adicionados a qualquer destino `android_binary` que dependa dessa biblioteca. Os arquivos incluídos aqui precisam ter apenas regras idempotentes, ou seja, -dontnote, -dontwarn, assumenosideeffects e regras que começam com -keep. Outras opções só podem aparecer em proguard_specs de `android_binary` para garantir mesclagens não tautológicas.
`resource_jars`	Lista de rótulos; o padrão é `[]` Descontinuado: use java_import e deps ou runtime_deps.
`resource_strip_prefix`	String; o padrão é `""` O prefixo do caminho a ser removido dos recursos Java. Se especificado, esse prefixo de caminho é removido de todos os arquivos no atributo `resources`. É um erro um arquivo de recurso não estar nesse diretório. Se não for especificado (padrão), o caminho do arquivo de recurso será determinado de acordo com a mesma lógica do pacote Java de arquivos de origem. Por exemplo, um arquivo de origem em `stuff/java/foo/bar/a.txt` será localizado em `foo/bar/a.txt`.

java_runtime

Acessar a origem da regra

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

Especifica a configuração de um ambiente de execução Java.

Exemplo:

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

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`srcs`	Lista de rótulos; o padrão é `[]` Todos os arquivos no tempo de execução.
`default_cds`	Rótulo: o padrão é `None`. Arquivo de CDS padrão para `java_runtime` hermético. Quando a hermeticidade está ativada para um destino `java_binary` e se o destino não fornece o próprio arquivo CDS especificando o atributo `classlist`, o CDS padrão `java_runtime` é empacotado no JAR de implantação hermética.
`hermetic_srcs`	Lista de rótulos; o padrão é `[]` Arquivos no ambiente de execução necessários para implantações herméticas.
`java`	Rótulo: o padrão é `None`. O caminho para o executável Java.
`java_home`	String; o padrão é `""` O caminho para a raiz do ambiente de execução. Sujeito à substituição da variável"Make". Se esse caminho for absoluto, a regra denotará um ambiente de execução Java não hermético com um caminho conhecido. Nesse caso, os atributos `srcs` e `java` precisam estar vazios.
`lib_ct_sym`	Rótulo: o padrão é `None`. O arquivo lib/ct.sym é necessário para a compilação com `--release`. Se não for especificado e houver exatamente um arquivo em `srcs` cujo caminho termine com `/lib/ct.sym`, esse arquivo será usado.
`lib_modules`	Rótulo: o padrão é `None`. O arquivo lib/modules necessário para implantações herméticas.
`version`	Inteiro; padrão é `0` A versão do recurso do ambiente de execução do Java. Ou seja, o número inteiro retornado por `Runtime.version().feature()`.

java_toolchain

Acessar a origem da regra

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_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jvm_opts, licenses, oneversion, oneversion_allowlist_for_tests, 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)

Especifica a configuração do compilador Java. É possível mudar qual toolchain será usado usando o argumento --java_toolchain. Normalmente, não é necessário escrever esse tipo de regra, a menos que você queira ajustar seu compilador Java.

Exemplos

Um exemplo simples seria:

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",
)

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`android_lint_data`	Lista de rótulos; o padrão é `[]` Rótulos de ferramentas disponíveis para expansão de rótulos em android_lint_jvm_opts.
`android_lint_jvm_opts`	Lista de strings. O padrão é `[]`. A lista de argumentos para a JVM ao invocar o Android Lint.
`android_lint_opts`	Lista de strings. O padrão é `[]`. A lista de argumentos do Android Lint.
`android_lint_package_configuration`	Lista de rótulos; o padrão é `[]` Configuração do Android Lint que precisa ser aplicada aos grupos de pacotes especificados.
`android_lint_runner`	Rótulo: o padrão é `None`. Rótulo do executor do Android Lint, se houver.
`bootclasspath`	Lista de rótulos; o padrão é `[]` As entradas de bootclasspath de destino Java. Corresponde à flag -bootclasspath do javac.
`deps_checker`	Lista de rótulos; o padrão é `[]` Rótulo do jar do deploy do ImportDepsChecker.
`forcibly_disable_header_compilation`	Booleano; o padrão é `False` Substituições de --java_header_compilation para desativar a compilação de cabeçalho em plataformas que não oferecem suporte a ela, como o JDK 7 Bazel.
`genclass`	Lista de rótulos; obrigatório Rótulo do jar do GenClass deploy.
`header_compiler`	Lista de rótulos; o padrão é `[]` Rótulo do compilador de cabeçalho. Obrigatório se --java_header_compilation estiver ativado.
`header_compiler_direct`	Lista de rótulos; o padrão é `[]` Rótulo opcional do compilador de cabeçalho a ser usado para ações de classpath diretas que não includem processadores de anotação que geram API. Essa ferramenta não oferece suporte ao processamento de anotações.
`ijar`	Lista de rótulos; obrigatório Rótulo do executável ijar.
`jacocorunner`	Rótulo: o padrão é `None`. Rótulo do jar deployment do JacocoCoverageRunner.
`java_runtime`	Rótulo: obrigatório O java_runtime a ser usado com esse conjunto de ferramentas. O padrão é java_runtime na configuração de execução.
`javabuilder`	Lista de rótulos; obrigatório Rótulo do jar do JavaBuilder.
`javabuilder_data`	Lista de rótulos; o padrão é `[]` Rótulos de dados disponíveis para expansão de rótulos em javabuilder_jvm_opts.
`javabuilder_jvm_opts`	Lista de strings. O padrão é `[]`. A lista de argumentos para a JVM ao invocar o JavaBuilder.
`javac_supports_multiplex_workers`	Booleano; o padrão é `True` Verdadeiro se o JavaBuilder oferece suporte à execução como um worker persistente multiplex, falso se não oferece.
`javac_supports_worker_multiplex_sandboxing`	Booleano; o padrão é `False` Verdadeiro se o JavaBuilder oferece suporte a sandboxes multiplex, falso se não oferece.
`javac_supports_workers`	Booleano; o padrão é `True` Verdadeiro se o JavaBuilder oferece suporte à execução como worker persistente, falso se não oferece.
`javacopts`	Lista de strings. O padrão é `[]`. A lista de argumentos extras para o compilador Java. Consulte a documentação do compilador Java para conferir uma lista completa de flags possíveis.
`jvm_opts`	Lista de strings. O padrão é `[]`. A lista de argumentos para a JVM ao invocar o compilador Java. Consulte a documentação da máquina virtual Java para conferir uma lista completa de flags possíveis para essa opção.
`oneversion`	Rótulo: o padrão é `None`. Rótulo do binário de aplicação de uma versão.
`oneversion_allowlist_for_tests`	Rótulo: o padrão é `None`. Rótulo da lista de permissões de uma versão para testes.
`oneversion_whitelist`	Rótulo: o padrão é `None`. Rótulo da lista de permissões de uma versão.
`package_configuration`	Lista de rótulos; o padrão é `[]` Configuração que precisa ser aplicada aos grupos de pacotes especificados.
`proguard_allowlister`	Rótulo: o padrão é `"@bazel_tools//tools/jdk:proguard_whitelister"`. Rótulo do white lister do Proguard.
`resourcejar`	Lista de rótulos; o padrão é `[]` Rótulo do executável do builder de jar de recursos.
`singlejar`	Lista de rótulos; obrigatório Rótulo do jar de implantação do SingleJar.
`source_version`	String; o padrão é `""` A versão do código-fonte Java (por exemplo, '6' ou '7'). Ele especifica quais conjuntos de estruturas de código são permitidos no código-fonte Java.
`target_version`	String; o padrão é `""` A versão de destino do Java (por exemplo, '6' ou '7'). Ele especifica para qual ambiente de execução Java a classe precisa ser criada.
`timezone_data`	Rótulo: o padrão é `None`. Rótulo de um jarro de recursos que contém dados de fuso horário. Se definido, os dados de fuso horário são adicionados como uma dependência implícita do ambiente de execução de todas as regras java_binary.
`tools`	Lista de rótulos; o padrão é `[]` Rótulos de ferramentas disponíveis para expansão de rótulos em jvm_opts.
`turbine_data`	Lista de rótulos; o padrão é `[]` Rótulos de dados disponíveis para expansão de rótulos em turbine_jvm_opts.
`turbine_jvm_opts`	Lista de strings. O padrão é `[]`. A lista de argumentos para a JVM ao invocar o Turbine.
`xlint`	Lista de strings. O padrão é `[]`. A lista de avisos a serem adicionados ou removidos da lista padrão. Use um traço para removê-lo. Consulte a documentação do Javac sobre as opções -Xlint para mais informações.