bazel: incompatible_use_remotejdk_as_host_javabase: use remote JDK for building Java

The option --incompatible_use_remotejdk_as_host_javabase allows us to remove the dependency from the host javabase on the embedded JDK.

More discussion in: https://docs.google.com/document/d/11OGJ2QTjnZgxbkgVFrKa3eD2DQ68qnXws7UQ1czc-qQ/edit#heading=h.5dewu068k9gb

Migration notes

  • If you set the flag, Bazel will download the JDK from a remote repository (see https://github.com/bazelbuild/bazel/pull/6216/files#diff-b53d77ce419e665f48b6c7bca4965357).
  • That JDK will be used to run the Java compiler (cf --host_javabase)
  • This will only happen if you actually build Java or use $(JAVA) or $(JAVABASE) in your genrules. Non-java devs are not affected.
  • If you want to avoid downloading the JDK (e.g. in CI settings) for Java builds, you can explicitly set the --host_javabase, e.g., to @local_jdk//:jdk.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 21 (14 by maintainers)

Commits related to this issue

Most upvoted comments

Ok, I can see how the default no-flag behavior is helpful to Java developers - they get the fully-featured toolchain with no configuration.

However, this change feels hostile to organizations that attempt to control their third-party dependencies (on both code and systems). Bazel has a mechanism for requesting third-party artifacts that is auditable - the WORKSPACE file. The fact that something outside of the WORKSPACE file gets downloaded by default is troubling, because now auditing third-party artifacts and systems the build is dependent on is a non-trivial task.

Scott, if you’re worried about the download, just set the host_javabase explicitly, e.g. to something vendored or the local jdk.

Yes, that is the current path forward for me. Thanks for documenting the workaround here, so that I know what to do.

I’m trying to say that this change, while it has convenient default behavior for some use cases, is surprising as well. All our other toolchains (C++, Go, protobuf) use locally-installed components; if there are downloads, those are set up via Starlark in the WORKSPACE file, which requires project owners to opt-in to downloads and consequently the systems they download from. Bazel has not, as far as I know, downloaded extra non-WORKSPACE-specified artifacts during the build, until now (please correct me if I’m wrong!). Teams that are not paying attention to these updates and flag-flips just got opted-in to a build-time dependency on external packages and systems. This is important to orgs that have strict policies around such things.

I’d prefer to see a change where the default behavior is a non-downloading one. I’d prefer that some amount of Starlark be inserted in the WORKSPACE file to trigger this remotejdk download (even if it’s a one-liner). To my knowledge, this is how all other toolchains must do things. I’d be curious to know if there’s a technical reason why Java can’t follow the same pattern, or what the rationale for this usability tradeoff is here.

BUT - at the end of the day, this isn’t my project; this is just one user’s perspective. I do appreciate your time and development effort.

If you want to avoid downloading the JDK (e.g. in CI settings) for Java builds, you can explicitly set the --host_javabase, e.g., to @local_jdk//:jdk.

Another approach is to include bazel build //... in CI docker image build step. Then the right JDK will be downloaded and cached in CI Docker image.