Skip to main content

Rules

java_binary

View rule sourceopen_in_new
Builds a Java archive (“jar file”), plus a wrapper shell script with the same name as the rule. The wrapper shell script uses a classpath that includes, among other things, a jar file for each library on which the binary depends. When running the wrapper shell script, any nonempty JAVABIN environment variable will take precedence over the version specified via Bazel’s --java_runtime_version flag. The wrapper script accepts several unique flags. Refer to //src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt for a list of configurable flags and environment variables accepted by the wrapper.

Implicit output targets

  • name.jar: A Java archive, containing the class files and other resources corresponding to the binary’s direct dependencies.
  • name-src.jar: An archive containing the sources (“source jar”).
  • name_deploy.jar: A Java archive suitable for deployment (only built if explicitly requested). Building the <name>_deploy.jar target for your rule creates a self-contained jar file with a manifest that allows it to be run with the java -jar command or with the wrapper script’s --singlejar option. Using the wrapper script is preferred to java -jar because it also passes the JVM flags and the options to load native libraries. The deploy jar contains all the classes that would be found by a classloader that searched the classpath from the binary’s wrapper script from beginning to end. It also contains the native libraries needed for dependencies. These are automatically loaded into the JVM at runtime. If your target specifies a launcher attribute, then instead of being a normal JAR file, the _deploy.jar will be a native binary. This will contain the launcher plus any native (C++) dependencies of your rule, all linked into a static binary. The actual jar file’s bytes will be appended to that native binary, creating a single binary blob containing both the executable and the Java code. You can execute the resulting jar file directly like you would execute any native binary.
  • name_deploy-src.jar: An archive containing the sources collected from the transitive closure of the target. These will match the classes in the deploy.jar except where jars have no matching source jar.
It is good practice to use the name of the source file that is the main entry point of the application (minus the extension). For example, if your entry point is called Main.java, then your name could be Main. A deps attribute is not allowed in a java_binary rule without srcs; such a rule requires a main_class provided by runtime_deps. The following code snippet illustrates a common mistake:
Do this instead:

Arguments

java_import

View rule sourceopen_in_new
This rule allows the use of precompiled .jar files as libraries for java_library and java_binary rules.

Examples

Arguments

java_library

View rule sourceopen_in_new
This rule compiles and links sources into a .jar file.

Implicit outputs

  • libname.jar: A Java archive containing the class files.
  • libname-src.jar: An archive containing the sources (“source jar”).

Arguments

java_test

View rule sourceopen_in_new
A java_test() rule compiles a Java test. A test is a binary wrapper around your test code. The test runner’s main method is invoked instead of the main class being compiled.

Implicit output targets

  • name.jar: A Java archive.
  • name_deploy.jar: A Java archive suitable for deployment. (Only built if explicitly requested.) See the description of the name_deploy.jar output from java_binary for more details.
See the section on java_binary() arguments. This rule also supports all attributes common to all test rules (*_test).

Examples

Arguments

java_package_configuration

View rule sourceopen_in_new
Configuration to apply to a set of packages. Configurations can be added to java_toolchain.javacoptss.

Example:

Arguments

java_plugin

View rule sourceopen_in_new
java_plugin defines plugins for the Java compiler run by Bazel. The only supported kind of plugins are annotation processors. A java_library or java_binary rule can run plugins by depending on them via the plugins attribute. A java_library can also automatically export plugins to libraries that directly depend on it using exported_plugins.

Implicit output targets

  • libname.jar: A Java archive.
Arguments are identical to java_library, except for the addition of the processor_class argument.

Arguments

java_runtime

View rule sourceopen_in_new
Specifies the configuration for a Java runtime.

Example:

Arguments

java_toolchain

View rule sourceopen_in_new
Specifies the configuration for the Java compiler. Which toolchain to be used can be changed through the —java_toolchain argument. Normally you should not write those kind of rules unless you want to tune your Java compiler.

Examples

A simple example would be:

Arguments