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.