Regras do Java

Informar um problema Acessar fonte

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

Confira a origem da regra

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"), além de um script de shell wrapper com o mesmo nome da regra. O script de shell do wrapper usa um caminho de classe 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 não vazia terá precedência sobre a versão especificada pela sinalização --java_runtime_version do Bazel.

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

Destinos de saída implícitos

• name.jar: um arquivo Java, contendo 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 (criado apenas se for explicitamente solicitado).

  Criar o destino <name>_deploy.jar para sua 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. É preferível usar o script de wrapper em vez de java -jar porque ele também transmite as sinalizações da JVM e as opções para carregar bibliotecas nativas.

  O jar de implantação contém todas as classes que seriam encontradas por um carregador de classe que pesquisou o caminho de classe no script de 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, em vez de ser um arquivo JAR normal, _deploy.jar será um binário nativo. Isso conterá a tela de início e todas as dependências nativas (C++) da regra, todas vinculadas a um binário estático. Os bytes do arquivo jar real serão anexados a esse binário nativo, criando um único blob binário contendo o código executável e o Java. É possível 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 do fechamento transitivo do destino. Eles corresponderão à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 abaixo ilustra um erro comum:

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

Em vez disso, faça o seguinte:

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

Argumentos

Atributos
name	Nome (obrigatório) Um nome exclusivo para o destino. É 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, o nome poderá ser Main.
deps	Lista de rótulos. O padrão é []. A lista de outras bibliotecas a serem vinculadas ao destino. Veja 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 processados para criar o destino. Esse atributo é quase sempre obrigatório. Consulte 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 de geração aqui, em vez do nome do próprio arquivo. Isso não apenas melhora a legibilidade, mas torna a regra mais resiliente a alterações futuras. Se a regra de geração gerar arquivos diferentes no futuro, você só precisará corrigir um local: o outs da regra de geração. Não liste a regra de geração em deps porque ela é um ambiente autônomo. 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 regra geral. Regras: se a regra (normalmente genrule ou filegroup) gerar qualquer um dos arquivos listados acima, ele será usado da mesma maneira descrita para os arquivos de origem. Esse argumento quase sempre é obrigatório, exceto se um atributo main_class especificar uma classe no caminho de classe 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 Java. Se os recursos forem especificados, eles serão agrupados no jar com os arquivos .class comuns produzidos por compilação. O local dos recursos dentro do arquivo jar é determinado pela estrutura do projeto. Primeiro, o Bazel procura o layout de diretório padrão do Maven, (um diretório "src" seguido de um neto do diretório "resources"). Se ele não for encontrado, o Bazel procurará o diretório superior 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. No entanto, 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 arquivos gerados.
classpath_resources	Lista de rótulos. O padrão é []. NÃO USE ESTA OPÇÃO, A NÃO SER QUE HÁ DE OUTRA FORMA) Uma lista de recursos que precisam estar localizados na raiz da árvore Java. A única finalidade desse atributo é oferecer suporte a bibliotecas de terceiros que exigem que os recursos sejam encontrados no caminho de classe como exatamente "myconfig.xml". Ele só é permitido em binários, e não em bibliotecas, devido ao risco de conflitos de namespace.
create_executable	Booleano, nonconfigurable. 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 do binário. Defina esse atributo ao criar um plug-in que será carregado por outro java_binary. A definição desse atributo exclui todas as dependências do caminho de classe do ambiente de execução (e o jar de implantação) desse binário compartilhadas entre o 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 destino *_deploy.jar. O conteúdo desse atributo não está sujeito à substituição "Make variables".
javacopts	Lista de strings. O padrão é []. Opções de compilador extras para essa biblioteca. Sujeito à substituição "Make variables" e à tokenização do shell Bourne. Essas opções do compilador são passadas para javac após as opções do compilador global.
jvm_flags	Lista de strings. O padrão é []. Uma lista de sinalizações a serem incorporadas no script de wrapper gerado para executar este binário. Sujeito à substituição $(location) e "Make variables", além da tokenização do shell Bourne. O script de wrapper de um binário Java inclui uma definição CLASSPATH (para encontrar todos os jars dependentes) e invoca o intérprete Java correto. A linha de comando gerada pelo script de 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 de wrapper antes que o nome da classe seja listado. Esse atributo não tem efeito nas saídas *_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 especificada como um valor para esse atributo. Por padrão, o Bazel usa o inicializador normal do JDK (bin/java ou java.exe). A sinalização Bazel --java_launcher relacionada afeta apenas os destinos java_binary e java_test que não especificaram um atributo launcher. Observe que as dependências nativas (C++, SWIG, JNI) serão compiladas de forma diferente, dependendo se você estiver usando a tela de início do JDK ou outra tela de início: Se você estiver usando a tela de início normal do JDK (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 outra tela de início, as dependências nativas (C++) serão estaticamente vinculadas a um binário chamado {name}_nativedeps, em que {name} é o atributo name dessa regra java_binary. Nesse caso, o vinculador removerá qualquer código considerado não utilizado do binário resultante, o que significa que qualquer código C++ acessado somente via JNI poderá não ser vinculado, a menos que o destino cc_library especifique alwayslink = 1. Ao usar qualquer tela de início diferente da tela de início padrão do JDK, o formato da saída *_deploy.jar muda. Consulte os principais documentos 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 de srcs=[...]. Assim, com esse atributo, é possível tornar 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 (de 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 do tempo de build.
plugins	Lista de rótulos. O padrão é []. Plug-ins do compilador Java para execução durante a compilação. Cada java_plugin especificado nesse atributo será executado sempre que a 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 é []. Obsoleto: 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 se um arquivo de recurso não estiver nesse diretório. Se não for especificado (o padrão), o caminho do arquivo de recursos 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 estará localizado em foo/bar/a.txt.
runtime_deps	Lista de rótulos. O padrão é []. Bibliotecas a serem disponibilizadas para o binário final ou teste apenas no momento da execução. Como as deps comuns, elas vão aparecer no caminho de classe de execução, mas, diferentemente deles, não no caminho de classe do tempo de compilação. As dependências necessárias apenas no momento da 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	Número inteiro. O padrão é -1 Define se as informações do build serão codificadas no binário. Valores possíveis: stamp = 1: sempre marque as informações do build no binário, mesmo em builds --nostamp. Evite essa configuração, já que ela pode eliminar o armazenamento em cache remoto do binário e todas as ações downstream que dependam dele. stamp = 0: sempre substitua as informações do build por valores constantes. Isso fornece um bom armazenamento em cache dos resultados da compilação. stamp = -1: a incorporação de informações do build é controlada pela flag --[no]stamp. Binários carimbados não são recriados, a menos que as dependências deles mudem.
use_launcher	Booleano. O padrão é True. Define se o binário deve usar uma tela de início personalizada. Se o atributo for definido como falso, o atributo launcher e a flag --java_launcher relacionada serão ignorados para o destino.
use_testrunner	Booleano. O padrão é False. Use a classe do executor de testes (por padrão, com.google.testing.junit.runner.BazelTestRunner) 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 de sistema bazel.test_suite. Use isso para substituir o comportamento padrão, que é usar o executor de testes para regras java_test e não usá-lo 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 java_binary, mas ainda precisa usar o executor de testes como ponto de entrada principal. O nome de uma classe do executor de testes pode ser substituído pelo atributo main_class.

java_import

Confira a origem da regra

java_import(name, deps, data, add_exports, add_opens, 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, toolchains, 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 o destino.
deps	Lista de rótulos. O padrão é []. A lista de outras bibliotecas a serem vinculadas ao destino. Consulte java_library.deps.
data	Lista de rótulos. O padrão é []. A lista de arquivos necessários para esta regra no tempo de execução.
add_exports	Lista de strings. O padrão é []. Permite que esta biblioteca acesse o module ou o package fornecidos. Isso corresponde às sinalizações javac e JVM --add-exports=.
add_opens	Lista de strings. O padrão é []. Permite que essa biblioteca acesse de forma reflexiva a module ou a package especificada. Isso corresponde às sinalizações javac e JVM --add-opens=.
constraints	Lista de strings. O padrão é []. Restrições extras impostas a essa regra como uma biblioteca Java.
exports	Lista de rótulos. O padrão é []. Destinos a serem disponibilizados para os usuários desta regra. Consulte java_library.exports.
jars	Lista de rótulos (obrigatório) A lista de arquivos JAR fornecidos aos destinos Java que dependem do destino.
neverlink	Booleano. O padrão é False. Use essa biblioteca apenas para compilação, não durante a execução. Útil quando a biblioteca será fornecida pelo ambiente de execução durante a execução. Exemplos de bibliotecas como essa são as APIs de ambiente de desenvolvimento integrado para plug-ins desse ambiente ou tools.jar para qualquer biblioteca executada em um JDK padrão.
proguard_specs	Lista de rótulos. O padrão é []. Arquivos a serem usados como especificação do Proguard. Elas descrevem o conjunto de especificações a serem usadas pelo Proguard. Se especificado, eles serão adicionados a qualquer destino android_binary, dependendo dessa biblioteca. Os arquivos incluídos aqui só podem ter regras idempotentes, como -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 a serem disponibilizadas para o binário final ou teste 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

Confira a origem da regra

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

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

Saídas implícitas

• 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 o destino.
deps	Lista de rótulos. O padrão é []. A lista de bibliotecas que serão vinculadas a esta 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 listadas em deps estarão no caminho de classe no tempo de compilação dessa regra. Além disso, o fechamento transitivo dos deps, runtime_deps e exports vai estar no caminho de classe de execução. Por outro lado, os destinos no atributo data são incluídos nos arquivos de execução, mas não nos caminhos de classe de tempo de compilação e execução.
srcs	Lista de rótulos. O padrão é []. A lista de arquivos de origem processados para criar o destino. Esse atributo é quase sempre obrigatório. Consulte 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 de geração aqui, em vez do nome do próprio arquivo. Isso não apenas melhora a legibilidade, mas torna a regra mais resiliente a alterações futuras. Se a regra de geração gerar arquivos diferentes no futuro, você só precisará corrigir um local: o outs da regra de geração. Não liste a regra geradora em deps porque ela é um ambiente autônomo. 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 regra geral. Regras: se a regra (normalmente genrule ou filegroup) gerar qualquer um dos arquivos listados acima, ele será usado da mesma maneira descrita para os arquivos de origem. Os arquivos de origem do tipo .properties são tratados como recursos. Todos os outros arquivos são ignorados, desde que haja pelo menos um arquivo do tipo descrito acima. Caso contrário, será gerado um erro. Esse argumento é quase sempre obrigatório, exceto se você especificar o argumento runtime_deps.
data	Lista de rótulos. O padrão é []. A lista de arquivos necessários para essa biblioteca durante a 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 lugar nenhum. Se os arquivos data forem gerados, eles serão gerados pelo Bazel. Ao criar um teste que depende desse java_library, o Bazel copia ou vincula os arquivos data na área dos 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 Java. Os recursos podem ser arquivos de origem ou arquivos gerados. Se os recursos forem especificados, eles serão agrupados no jar com os arquivos .class comuns produzidos por compilação. A localização dos recursos dentro do arquivo jar é determinada pela estrutura do projeto. Primeiro, o Bazel procura o layout de diretório padrão (link em inglês) do Maven, (um diretório "src" seguido de um neto do diretório "resources"). Se ele não for encontrado, o Bazel vai procurar o diretório superior 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. No entanto, o atributo resource_strip_prefix pode ser usado para especificar um diretório alternativo específico para arquivos de recursos.
add_exports	Lista de strings. O padrão é []. Permite que esta biblioteca acesse o module ou o package fornecidos. Isso corresponde às sinalizações javac e JVM --add-exports=.
add_opens	Lista de strings. O padrão é []. Permite que essa biblioteca acesse de forma reflexiva a module ou a package especificada. Isso corresponde às sinalizações javac e JVM --add-opens=.
bootclasspath	Rótulo; o padrão é None API restrita, não use!
exported_plugins	Lista de rótulos. O padrão é []. A lista de java_plugins (por exemplo, processadores de anotações) a serem exportados para bibliotecas que dependem diretamente dessa biblioteca. A lista especificada de java_plugins será aplicada a qualquer biblioteca que dependa diretamente dessa biblioteca, como se essa biblioteca tivesse declarado explicitamente esses rótulos em plugins.
exports	Lista de rótulos. O padrão é []. Bibliotecas exportadas. Listar regras aqui as disponibilizará para as regras pai, como se os pais dependessem dessas regras explicitamente. Isso não é verdade para deps normais (não exportados). Resumo: uma regra X poderá acessar o código em Y se houver um caminho de dependência entre elas que comece com uma aresta deps seguida por zero ou mais arestas exports. Vejamos alguns exemplos para ilustrar isso. Suponha que A depende de B e B depende de C. Nesse caso, C é uma dependência transitiva de A, então mudar as origens de C e recriar A recriará tudo corretamente. No entanto, A não poderá usar classes em C. Para permitir isso, ou A precisa declarar C no deps, ou B pode facilitar para A (e qualquer coisa que dependa de A) declarando C no atributo exports (de B). O fechamento de bibliotecas exportadas está disponível para todas as regras mãe diretas. Veja 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 exportassem algumas bibliotecas, C' e D', respectivamente, A só poderia acessar C', mas não D'. Importante: uma regra exportada não é uma dependência normal. Considerando o exemplo anterior, se B exportar C e também quiser usar C, também será necessário listá-lo em seu próprio deps.
javabuilder_jvm_flags	Lista de strings. O padrão é []. API restrita, não use!
javacopts	Lista de strings. O padrão é []. Opções de compilador extras para essa biblioteca. Sujeito à substituição "Make variables" e à tokenização do shell Bourne. Essas opções do compilador são passadas para javac após as opções do compilador global.
neverlink	Booleano. O padrão é False. Define se a biblioteca precisa ser usada apenas para compilação e não no momento da execução. Útil quando a biblioteca será 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 desse ambiente ou tools.jar para qualquer versão em execução em um JDK padrão. neverlink = 1 não impede que o compilador incorpore o material dessa biblioteca em linha em destinos de compilação que dependam dele, conforme permitido pela especificação da linguagem Java (por exemplo, constantes static final de String ou de tipos primitivos). Portanto, o caso de uso recomendado é quando a biblioteca de ambiente de execução é idêntica à biblioteca de compilação. Se a biblioteca de tempo de execução for diferente da biblioteca de compilação, é necessário garantir que ela seja diferente apenas em locais em que o JLS proíbe os compiladores para serem inline (e isso precisa ser mantido para todas as versões futuras do JLS).
plugins	Lista de rótulos. O padrão é []. Plug-ins do compilador Java para execução durante a compilação. Cada java_plugin especificado nesse 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. Elas descrevem o conjunto de especificações a serem usadas pelo Proguard. Se especificado, eles serão adicionados a qualquer destino android_binary, dependendo dessa biblioteca. Os arquivos incluídos aqui só podem ter regras idempotentes, como -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_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 se um arquivo de recurso não estiver nesse diretório. Se não for especificado (o padrão), o caminho do arquivo de recursos 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 estará localizado em foo/bar/a.txt.
runtime_deps	Lista de rótulos. O padrão é []. Bibliotecas a serem disponibilizadas para o binário final ou teste apenas no momento da execução. Como as deps comuns, elas vão aparecer no caminho de classe de execução, mas diferentemente deles, não no caminho de classe do tempo de compilação. As dependências necessárias apenas no momento da 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

Confira a origem da regra

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

java_lite_proto_library gera código Java a partir de arquivos .proto.

deps precisa apontar para regras proto_library .

Exemplo:

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

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

proto_library(
    name = "bar",
)

Argumentos

Atributos
name	Nome (obrigatório) Um nome exclusivo para o destino.
deps	Lista de rótulos. O padrão é []. A lista de regras proto_library para as quais gerar código Java.

java_proto_library

Confira a origem da regra

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

java_proto_library gera código Java a partir de arquivos .proto.

deps precisa apontar para regras proto_library .

Exemplo:

java_library(
    name = "lib",
    runtime_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 o destino.
deps	Lista de rótulos. O padrão é []. A lista de regras proto_library para as quais gerar código Java.

java_test

Confira a origem da regra

java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, 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, neverlink, plugins, 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 testes é invocado em vez da classe principal que está sendo compilada.

Destinos de saída implícitos

• name.jar: um arquivo Java.
• name_deploy.jar: um arquivo Java adequado para implantação. Criada somente se explicitamente solicitada. Consulte a descrição da saída name_deploy.jar de java_binary para saber mais detalhes.

Consulte a seção sobre argumentos java_binary(). Essa regra também é compatível com 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 o destino.
deps	Lista de rótulos. O padrão é []. A lista de outras bibliotecas a serem 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 processados para criar o destino. Esse atributo é quase sempre obrigatório. Consulte 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 de geração aqui, em vez do nome do próprio arquivo. Isso não apenas melhora a legibilidade, mas torna a regra mais resiliente a alterações futuras. Se a regra de geração gerar arquivos diferentes no futuro, você só precisará corrigir um local: o outs da regra de geração. Não liste a regra geradora em deps porque ela é um ambiente autônomo. 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 regra geral. Regras: se a regra (normalmente genrule ou filegroup) gerar qualquer um dos arquivos listados acima, ele será usado da mesma maneira descrita para os arquivos de origem. Esse argumento quase sempre é obrigatório, exceto se um atributo main_class especificar uma classe no caminho de classe 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 durante a execução. Consulte comentários gerais sobre data em Atributos típicos definidos pela maioria das regras de build.
resources	Lista de rótulos. O padrão é []. Uma lista de arquivos de dados a serem incluídos em um jar Java. Os recursos podem ser arquivos de origem ou arquivos gerados. Se os recursos forem especificados, eles serão agrupados no jar com os arquivos .class comuns produzidos por compilação. A localização dos recursos dentro do arquivo jar é determinada pela estrutura do projeto. Primeiro, o Bazel procura o layout de diretório padrão (link em inglês) do Maven, (um diretório "src" seguido de um neto do diretório "resources"). Se ele não for encontrado, o Bazel vai procurar o diretório superior 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. No entanto, o atributo resource_strip_prefix pode ser usado para especificar um diretório alternativo específico para arquivos de recursos.
add_exports	Lista de strings. O padrão é []. Permite que esta biblioteca acesse o module ou o package fornecidos. Isso corresponde às sinalizações javac e JVM --add-exports=.
add_opens	Lista de strings. O padrão é []. Permite que essa biblioteca acesse de forma reflexiva a module ou a package especificada. Isso corresponde às sinalizações javac e JVM --add-opens=.
bootclasspath	Rótulo; o padrão é None API restrita, não use!
classpath_resources	Lista de rótulos. O padrão é []. NÃO USE ESTA OPÇÃO, A NÃO SER QUE HÁ DE OUTRA FORMA) Uma lista de recursos que precisam estar localizados na raiz da árvore Java. A única finalidade desse atributo é oferecer suporte a bibliotecas de terceiros que exigem que os recursos sejam encontrados no caminho de classe como exatamente "myconfig.xml". Devido ao risco de conflitos de namespace, ele só é permitido em binários, e não em bibliotecas.
create_executable	Booleano. 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 destino *_deploy.jar. O conteúdo desse atributo não está sujeito à substituição "Make variables".
javacopts	Lista de strings. O padrão é []. Opções extras do compilador para este binário. Sujeito à substituição "Make variables" e à tokenização do shell Bourne. Essas opções do compilador são passadas para javac após as opções do compilador global.
jvm_flags	Lista de strings. O padrão é []. Uma lista de sinalizações a serem incorporadas no script de wrapper gerado para executar este binário. Sujeito à substituição $(location) e "Make variables", além da tokenização do shell Bourne. O script de wrapper de um binário Java inclui uma definição CLASSPATH (para encontrar todos os jars dependentes) e invoca o intérprete Java correto. A linha de comando gerada pelo script de 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 de wrapper antes que o nome da classe seja listado. Observe que esse atributo não tem efeito nas saídas *_deploy.jar.
launcher	Rótulo; o padrão é None Especifique um binário que será usado para executar o 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 especificada como um valor para esse atributo. Por padrão, o Bazel usa o inicializador normal do JDK (bin/java ou java.exe). A sinalização --java_launcher do Bazel relacionada afeta apenas os destinos java_binary e java_test que não especificaram um atributo launcher. As dependências nativas (C++, SWIG, JNI) serão criadas de maneira diferente, dependendo se você estiver usando a tela de início do JDK ou outra tela de início: Se você estiver usando a tela de início normal do JDK (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 outra tela de início, as dependências nativas (C++) serão estaticamente vinculadas a um binário chamado {name}_nativedeps, em que {name} é o atributo name dessa regra java_binary. Nesse caso, o vinculador removerá qualquer código considerado não utilizado do binário resultante, o que significa que qualquer código C++ acessado somente via JNI poderá não ser vinculado, a menos que o destino cc_library especifique alwayslink = 1. Ao usar qualquer tela de início diferente da tela de início padrão do JDK, o formato da saída *_deploy.jar muda. Consulte a documentação principal do java_binary para ver 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 de srcs=[...]. Assim, com esse atributo, é possível tornar 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 (de 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 do tempo de build.
neverlink	Booleano. O padrão é False.
plugins	Lista de rótulos. O padrão é []. Plug-ins do compilador Java para execução durante a compilação. Cada java_plugin especificado nesse 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_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 se um arquivo de recurso não estiver nesse diretório. Se não for especificado (o padrão), o caminho do arquivo de recursos 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 estará localizado em foo/bar/a.txt.
runtime_deps	Lista de rótulos. O padrão é []. Bibliotecas a serem disponibilizadas para o binário final ou teste apenas no momento da execução. Como as deps comuns, elas vão aparecer no caminho de classe de execução, mas diferentemente deles, não no caminho de classe do tempo de compilação. As dependências necessárias apenas no momento da 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	Número inteiro. O padrão é 0 Define se as informações do build serão codificadas no binário. Valores possíveis: stamp = 1: sempre marque as informações do build no binário, mesmo em builds --nostamp. Evite essa configuração, já que ela pode eliminar o armazenamento em cache remoto do binário e todas as ações downstream que dependam dele. stamp = 0: sempre substitua as informações do build por valores constantes. Isso fornece um bom armazenamento em cache dos resultados da compilação. stamp = -1: a incorporação de informações do build é controlada pela flag --[no]stamp. Binários carimbados não são recriados, a menos que as dependências deles 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 no lugar. Defina a sinalização --nolegacy_bazel_java_test para não substituir o primeiro argumento. Esse atributo especifica o nome de uma classe Java a ser executada por este teste. É raro configurar isso. Se esse argumento for omitido, ele será inferido usando o name do destino e o caminho relativo da raiz da origem. Se o teste estiver localizado fora de uma raiz de origem conhecida, o Bazel informará um erro se test_class não estiver definido. Para 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). Para 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 a execução de 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. Define se o binário deve usar uma tela de início personalizada. Se ele for definido como falso, o atributo launcher e a flag --java_launcher relacionada serão ignorados para esse destino.
use_testrunner	Booleano. O padrão é True. Use a classe do executor de testes (por padrão, com.google.testing.junit.runner.BazelTestRunner) 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 de sistema bazel.test_suite. Esse método pode ser usado para substituir o comportamento padrão, que é usar o executor de testes para regras java_test e não usá-lo 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 java_binary, mas ainda precisa usar o executor de testes como o ponto de entrada principal. O nome de uma classe do executor de testes pode ser substituído pelo atributo main_class.

java_package_configuration

Confira a origem da regra

java_package_configuration(name, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, javacopts, output_licenses, packages, restricted_to, tags, target_compatible_with, testonly, toolchains, 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 o destino.
data	Lista de rótulos. O padrão é []. A lista de arquivos necessários para essa configuração no ambiente de execução.
javacopts	Lista de strings. O padrão é []. Sinalizações do compilador Java.
output_licenses	Lista de strings. O padrão é [].
packages	Lista de rótulos. O padrão é []. O conjunto de package_groups ao qual a configuração será aplicada.

java_plugin

Confira a origem da regra

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

java_plugin define plug-ins para o compilador Java executado pelo Bazel. No momento, o único tipo de plug-in compatível são processadores de anotações. Uma regra java_library ou java_binary pode executar plug-ins dependendo deles por meio do atributo plugins. Um java_library também pode exportar plug-ins automaticamente para bibliotecas que dependem diretamente dele usando exported_plugins.

Destinos 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 o destino.
deps	Lista de rótulos. O padrão é []. A lista de bibliotecas que serão vinculadas a esta 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 listadas em deps estarão no caminho de classe no tempo de compilação dessa regra. Além disso, o fechamento transitivo dos deps, runtime_deps e exports vai estar no caminho de classe de execução. Por outro lado, os destinos no atributo data são incluídos nos arquivos de execução, mas não nos caminhos de classe de tempo de compilação e execução.
srcs	Lista de rótulos. O padrão é []. A lista de arquivos de origem processados para criar o destino. Esse atributo é quase sempre obrigatório. Consulte 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 de geração aqui, em vez do nome do próprio arquivo. Isso não apenas melhora a legibilidade, mas torna a regra mais resiliente a alterações futuras. Se a regra de geração gerar arquivos diferentes no futuro, você só precisará corrigir um local: o outs da regra de geração. Não liste a regra geradora em deps porque ela é um ambiente autônomo. 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 regra geral. Regras: se a regra (normalmente genrule ou filegroup) gerar qualquer um dos arquivos listados acima, ele será usado da mesma maneira descrita para os arquivos de origem. Os arquivos de origem do tipo .properties são tratados como recursos. Todos os outros arquivos são ignorados, desde que haja pelo menos um arquivo do tipo descrito acima. Caso contrário, será gerado um erro. Esse argumento é quase sempre obrigatório, exceto se você especificar o argumento runtime_deps.
data	Lista de rótulos. O padrão é []. A lista de arquivos necessários para essa biblioteca durante a 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 lugar nenhum. Se os arquivos data forem gerados, eles serão gerados pelo Bazel. Ao criar um teste que depende desse java_library, o Bazel copia ou vincula os arquivos data na área dos 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 Java. Os recursos podem ser arquivos de origem ou arquivos gerados. Se os recursos forem especificados, eles serão agrupados no jar com os arquivos .class comuns produzidos por compilação. A localização dos recursos dentro do arquivo jar é determinada pela estrutura do projeto. Primeiro, o Bazel procura o layout de diretório padrão (link em inglês) do Maven, (um diretório "src" seguido de um neto do diretório "resources"). Se ele não for encontrado, o Bazel vai procurar o diretório superior 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. No entanto, o atributo resource_strip_prefix pode ser usado para especificar um diretório alternativo específico para arquivos de recursos.
add_exports	Lista de strings. O padrão é []. Permite que esta biblioteca acesse o module ou o package fornecidos. Isso corresponde às sinalizações javac e JVM --add-exports=.
add_opens	Lista de strings. O padrão é []. Permite que essa biblioteca acesse de forma reflexiva a module ou a package especificada. Isso corresponde às sinalizações javac e JVM --add-opens=.
bootclasspath	Rótulo; o padrão é None API restrita, não use!
generates_api	Booleano. O padrão é False. Esse atributo marca os processadores de anotações que geram o código da API. Se uma regra usar um processador de anotações que gera API, outras regras que dependem dela só poderão consultar o 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 somente se necessário.
javabuilder_jvm_flags	Lista de strings. O padrão é []. API restrita, não use!
javacopts	Lista de strings. O padrão é []. Opções de compilador extras para essa biblioteca. Sujeito à substituição "Make variables" e à tokenização do shell Bourne. Essas opções do compilador são passadas para javac após as opções do compilador global.
neverlink	Booleano. O padrão é False. Define se a biblioteca precisa ser usada apenas para compilação e não no momento da execução. Útil quando a biblioteca será 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 desse ambiente ou tools.jar para qualquer versão em execução em um JDK padrão. neverlink = 1 não impede que o compilador incorpore o material dessa biblioteca em linha em destinos de compilação que dependam dele, conforme permitido pela especificação da linguagem Java (por exemplo, constantes static final de String ou de tipos primitivos). Portanto, o caso de uso recomendado é quando a biblioteca de ambiente de execução é idêntica à biblioteca de compilação. Se a biblioteca de tempo de execução for diferente da biblioteca de compilação, é necessário garantir que ela seja diferente apenas em locais em que o JLS proíbe os compiladores para serem inline (e isso precisa ser mantido para todas as versões futuras do JLS).
output_licenses	Lista de strings. O padrão é [].
plugins	Lista de rótulos. O padrão é []. Plug-ins do compilador Java para execução durante a compilação. Cada java_plugin especificado nesse 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 de 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 vai ser incluído no caminho do processador de anotações do compilador. Isso se destina principalmente ao uso por plug-ins propensos a erros, que são carregados pelo 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. Elas descrevem o conjunto de especificações a serem usadas pelo Proguard. Se especificado, eles serão adicionados a qualquer destino android_binary, dependendo dessa biblioteca. Os arquivos incluídos aqui só podem ter regras idempotentes, como -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_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 se um arquivo de recurso não estiver nesse diretório. Se não for especificado (o padrão), o caminho do arquivo de recursos 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 estará localizado em foo/bar/a.txt.

java_runtime

Confira a origem da regra

java_runtime(name, srcs, compatible_with, default_cds, deprecation, distribs, exec_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)

Especifica a configuração de um ambiente de execução do 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 o destino.
srcs	Lista de rótulos. O padrão é []. Todos os arquivos no ambiente de execução.
default_cds	Rótulo; o padrão é None Arquivo CDS padrão para java_runtime hermético. Quando o hermético está ativado 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.
hermetic_static_libs	Lista de rótulos. O padrão é []. As bibliotecas que estão estaticamente vinculadas ao inicializador 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 de 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 compilação com --release. Se não for especificado e houver exatamente um arquivo em srcs com caminho terminando em /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.
output_licenses	Lista de strings. O padrão é [].
version	Número inteiro. O 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

Confira 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_javacopts, compatible_with, deprecation, deps_checker, distribs, exec_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)

Especifica a configuração do compilador Java. O conjunto de ferramentas a ser usado pode ser alterado por meio do argumento --java_dataset. Normalmente, não é recomendável 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 o destino.
android_lint_data	Lista de rótulos. O padrão é []. Rótulos das ferramentas disponíveis para expansão de rótulo 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 é []. Lista de argumentos do Android Lint.
android_lint_package_configuration	Lista de rótulos. O padrão é []. Configuração do lint do Android que precisa ser aplicada aos grupos de pacotes especificados.
android_lint_runner	Rótulo; o padrão é None Identificador do executor do Android Lint, se houver.
bootclasspath	Lista de rótulos. O padrão é []. As entradas bootclasspath de destino do Java. Corresponde à sinalização -bootclasspath do javac.
compatible_javacopts	null; default is {} API interna, não use!
deps_checker	Rótulo; o padrão é None Identificador do jar de implantação ImportDepsChecker.
forcibly_disable_header_compilation	Booleano. O padrão é False. Modifica --java_header_compilation para desativar a compilação de cabeçalhos em plataformas que não oferecem suporte a ela, por exemplo, JDK 7 Bazel.
genclass	Rótulo; o padrão é None Identificador do jar de implantação da GenClass.
header_compiler	Rótulo; o padrão é None Identificador do compilador do cabeçalho. Obrigatório se --java_header_compilation estiver ativado.
header_compiler_builtin_processors	Lista de strings. O padrão é []. API interna, não use!
header_compiler_direct	Rótulo; o padrão é None Rótulo opcional do compilador de cabeçalho a ser usado para ações diretas de caminho de classe que não incluem processadores de anotações que geram API. Esta ferramenta não tem suporte ao processamento de anotações.
ijar	Rótulo; o padrão é None Identificador do executável ijar.
jacocorunner	Rótulo; o padrão é None Identificador do jar de implantação do JacocoCoverageRunner.
java_runtime	Rótulo; o padrão é None O java_runtime a ser usado com este conjunto de ferramentas. O padrão é java_runtime na configuração de execução.
javabuilder	Rótulo; o padrão é None Rótulo do jar de implantação do JavaBuilder.
javabuilder_data	Lista de rótulos. O padrão é []. Rótulos de dados disponíveis para expansão de rótulo 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 for compatível com a execução como um worker persistente multiplex; caso contrário, será falso.
javac_supports_worker_cancellation	Booleano. O padrão é True. Verdadeiro se o JavaBuilder oferecer suporte ao cancelamento de workers persistentes; falso se não for.
javac_supports_worker_multiplex_sandboxing	Booleano. O padrão é False. Verdadeiro se o JavaBuilder oferece suporte à execução como um worker persistente multiplex com sandbox; falso se não for.
javac_supports_workers	Booleano. O padrão é True. Verdadeiro se o JavaBuilder oferece suporte à execução como um worker persistente; caso contrário, será falso.
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 a lista completa de possíveis flags do compilador Java.
jspecify_implicit_deps	Rótulo; o padrão é None Experimental, não use!
jspecify_javacopts	Lista de strings. O padrão é []. Experimental, não use!
jspecify_packages	Lista de rótulos. O padrão é []. Experimental, não use!
jspecify_processor	Rótulo; o padrão é None Experimental, não use!
jspecify_processor_class	String. O padrão é "". Experimental, não use!
jspecify_stubs	Lista de rótulos. O padrão é []. Experimental, não use!
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 ver a lista completa de possíveis sinalizações para essa opção.
misc	Lista de strings. O padrão é []. Obsoleto: use javacopts
oneversion	Rótulo; o padrão é None Identificador do binário de aplicação de uma versão.
oneversion_allowlist_for_tests	Rótulo; o padrão é None Identificador 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 da lista de permissões do Proguard.
reduced_classpath_incompatible_processors	Lista de strings. O padrão é []. API interna, não use!
singlejar	Rótulo; o padrão é None Identificador do jar de implantação do SingleJar.
source_version	String. O padrão é "". A versão de origem Java (por exemplo, "6" ou "7"). Ela especifica qual conjunto de estruturas de código são permitidas no código-fonte em 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 do Java a classe precisa ser criada.
timezone_data	Rótulo; o padrão é None Rótulo de um jar de recurso que contém dados de fuso horário. Se definido, os dados de fuso horário serão adicionados como uma dependência implícita de tempo 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 do rótulo em jvm_opts.
turbine_data	Lista de rótulos. O padrão é []. Rótulos de dados disponíveis para expansão de rótulo em turbine_jvm_opts.
turbine_jvm_opts	Lista de strings. O padrão é []. A lista de argumentos para a JVM ao invocar a turbina.
xlint	Lista de strings. O padrão é []. A lista de avisos a serem adicionados ou removidos da lista padrão. Ela começa com um traço, antes de ela ser removida. Consulte a documentação do Javac sobre as opções -Xlint para obter mais informações.