incompatible_use_remotejdk_as_host_javabase: use remote JDK for building Java

[meisterT]

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.

[meisterT]

We plan to flip the flag (and remove the old code) in the 0.21 release.

[dslomov]

Could you write a more concise explanation in the issue of

• what the flag does
• who is affected
• how to fix

[dslomov]

(once that is done, add 'migration-0.20' and 'breaking-change-0.21' labels back.

[meisterT]

• 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).
• This will only happen if you actually build Java or use $(JAVA) or $(JAVABASE) in your genrules. Non-java devs are not affected.
• How to fix: the version of the embedded JDK and the new default JDK are identical. And I already pointed out how to do work around the additional download (if necessary) in the first comment.

[davido]

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.

[Monnoroch]

@davido probably better to include bazel sync.

[scottmin0r]

Philosophical question - why is the default behavior (after the flag is flipped) to download from a remote repository, unless this is opted out by specifying --host_javabase=@local_jdk//:jdk? This might be convenient for some use cases, but it has some drawbacks:

• The version of the JDK used is effectively hardcoded into bazel; future bazel versions can bump the JDK version, forcing users to effectively update JDK versions on bazel's schedule rather than their own
• (the one I care more about) bazel now (possibly) has a build-time dependency on an external system with no corresponding WORKSPACE entry to audit

From the above linked doc, one of the reasons for doing this is:

It will align how we handle toolchains for different languages (e.g. Bazel doesn’t come with a C++ compiler).

By default, bazel doesn't download a C++ compiler from the internet at build time, either (I hope!) unless you have the WORKSPACE entries to explicitly do exactly that. Why should the Java toolchain be any different?

[davido]

Why should the Java toolchain be any different?

Is this because Java tool chain is patched by Bazel team to support JavaBuilder's additional features? If you build with vanilla java builder then these features would be lost:

# The 'vanilla' toolchain is an unsupported alternative to the default.
#
# It does not provider any of the following features:
#   * Error Prone
#   * Strict Java Deps
#   * Header Compilation
#   * Reduced Classpath Optimization

[scottmin0r]

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.

[meisterT]

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

[davido]

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

+1. Today Bazel still doesn't support Java 11 as target java version on their default toolchain (sadly). However, check this Gerrit instruction how one can still produce Java 11 byte code with Bazel using vanilla build tool chain. But note, that all those neat features I mentioned above would be lost:

$ bazel build \
    --define=ABSOLUTE_JAVABASE=/usr/lib64/jvm/jre-11-openjdk \
    --host_javabase=@bazel_tools//tools/jdk:absolute_javabase \
    --host_java_toolchain=@bazel_tools//tools/jdk:toolchain_vanilla \
    --java_toolchain=@bazel_tools//tools/jdk:toolchain_vanilla \
    :release

[scottmin0r]

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.

[meisterT]

Scott, thanks for your feedback. This also might be the direction in which we will be moving for Java.

Instead of coupling the steps together we decided to do baby steps (same JDK version as before etc) to break as few people as possible.

[SimonBoorer]

This change prevents bootstrapping 0.21.0 without network access unless you set host_javabase explicitly (e.g. --host_javabase=@local_jdk//:jdk). It would be good if this was documented in the compilation instructions, but also this seems contradictory to the stance taken with @desugar_jdk_libs in #5202.

[meisterT]

Simon, thanks for reporting. We have a couple of options how to fix that:
a) document to set EXTRA_BAZEL_ARGS if you want to build without network
b) include the remote JDKs in the bazel dist archive
c) explicitly set --host_javabase to the local_jdk (so it can be overridden by the user, but defaults to it). We require a JDK to be installed anyway.

Any preferences from your side?
cc @aehlig who spent some time working on bootstrapping w/o network.

[aehlig]

cc @aehlig who spent some time working on bootstrapping w/o network.

At the very least we can document that --host_javabase has to be set. This is my proposal to do so: https://bazel-review.googlesource.com/c/bazel/+/87850.

The good news is, that we're already testing (since f250784) that bazel can be bootstrapped offline, so //src/test/shell/bazel:bazel_bootstrap_distfile_test can serve as a machine-verified documentation for building bazel from source. Setting --host_javabase is also what the FreeBSD port does since its update to 0.21.0, precisely in order to be able to build offline.

[brendandouglas]

For reference, because of #6035, if you set --host_javabase (as this breaking change can require) you might also need to set the toolchain flags if you want the same behavior as v0.20 in an offline environment.

I found I needed to set all of host_javabase, javabase, host_java_toolchain, and java_toolchain, to get my project building offline:

--host_javabase=@local_jdk//:jdk \
--javabase=@local_jdk//:jdk \
--host_java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8 \
--java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8

[hoffbrinkle]

This will only happen if you actually build Java or use $(JAVA) or $(JAVABASE) in your genrules. Non-java devs are not affected.

This is the bit that's biting me right now. I'm required to build in an environment with no network access, so it's immediately obvious. I do not believe I "build Java" and I certainly am not using $(JAVA) or $(JAVABASE) in genrule. However, when I attempt to run my tests:

external/bazel_tools/tools/jdk/BUILD:341:1: no such package '@remotejdk10_linux//': java.io.IOException: thread interrupted and referenced by '@bazel_tools//tools/jdk:remote_jdk10'

The good news is that I can use the --host_javabase in order to make the upgrade, but I'm thinking I really shouldn't have to do that if I'm not using Java.

[meisterT]

@hoffbrinkle, which Bazel version do you use and what languages do you have in your build?

[hoffbrinkle]

@hoffbrinkle, which Bazel version do you use and what languages do you have in your build?

I'm currently using 0.20.0 with --all_incompatible_changes (though I see this behavior in 0.25.2 as well). I can recreate with the following BUILD file:

sh_test(
    name = "foo",
    srcs = ["foo.sh"],
)

and foo.sh:

#!/bin/bash
exit

[meisterT]

Thanks, I filed #8355