Verify bootclasspath version is at most compilation runtime version

[fmeum]

The bootclasspath is loaded by the Java toolchain's runtime used for compilation and thus needs to be compatible with it, otherwise this triggers errors such as:

error: cannot access module-info
  bad class file: /modules/jdk.net/module-info.class
    class file has wrong version 64.0, should be 61.0
    Please remove or make sure it appears in the correct subdirectory of the classpath.
error: cannot access module-info
  bad class file: /modules/jdk.accessibility/module-info.class
    class file has wrong version 64.0, should be 61.0
    Please remove or make sure it appears in the correct subdirectory of the classpath.
error: cannot access module-info
  bad class file: /modules/jdk.internal.vm.compiler.management/module-info.class
    class file has wrong version 64.0, should be 61.0
    Please remove or make sure it appears in the correct subdirectory of the classpath.

Work towards #17281

[fmeum]

@cushon Could you review this PR? It implements one more version check that wasn't mentioned in #17281, but discovered in #18309.

The tests fail in CI as for some reason I don't understand - and only in CI - Bazel picks up remote JDKs from rules_java, which doesn't include 7556e11. As a side effect, this means that Bzlmod also won't be picking up java_runtime versions.

CC @comius

[meteorcloudy]

The tests fail in CI as for some reason I don't understand - and only in CI - Bazel picks up remote JDKs from rules_java, which doesn't include 7556e11. As a side effect, this means that Bzlmod also won't be picking up java_runtime versions.

This is due to the CI test setup to reusing remote JDKs fetched by the outter Bazel. Can be reproduced by:

$ bazel build //src:test_repos
$ bazel info output_base
/root/.cache/bazel/_bazel_root/c564d33b2d1d9ff3bd9f69877f355ccc
$ bazel test --test_env=TEST_REPOSITORY_HOME=/root/.cache/bazel/_bazel_root/c564d33b2d1d9ff3bd9f69877f355ccc/external //src/test/shell/bazel:bazel_with_jdk_test

The root cause is the remotejdk_**_for_testing repos are using a wrong BUILD file:

bazel/WORKSPACE

Line 313 in 03ca286

build_file = "@local_jdk//:BUILD.bazel",

Instead, the template at

bazel/tools/jdk/jdk_build_file.bzl

Line 17 in 03ca286

JDK_BUILD_TEMPLATE = """load("@rules_java//java:defs.bzl", "java_runtime")

should be used, sending a fix now

[meteorcloudy]

A even better solution is to switch to use rules_java as the only source of truth as discussed in #18373

[cushon]

Thanks, this generally LGTM

I wondered if there mgiht be any merit to doing this as runtime check. One benefit of that is that it avoids needing to set the version in BootClassPathInfo.

One disadvantage is that we'd have to spend a little time inspecting the bootclasspath before passing it to javac. Another disadvantage is that the error isn't reported to analysis time, but if we can provide a better error than error: cannot access module-info maybe that would be good enough?

[cushon]

I wondered about using OptionalInt in the Java code here, but I don't have a strong opinion. If starlark is using 0, it might be clearer to be consistent

[hvadehra]

Oops, this dropped off my radar somehow. @fmeum could you please rebase and resolve conflicts?

[fmeum]

Oops, this dropped off my radar somehow. @fmeum could you please rebase and resolve conflicts?

I can no longer reproduce the original failure. I will have to dig into this again.

[fmeum]

While investigating this, I ran into an actual bug: #19537

[fmeum]

When #19537 is fixed, I will implement this in JavaBuilder instead, as @cushon recommended. It should be possible to detect the diagnostic raised in this case and add a Bazel-specific note. This has the advantage that we don't fail in setups that work even though we think they shouldn't.

[fmeum]

At least partially superseded by #19547. The missing case is --java_language_version=8, but that currently doesn't result in an error because of #19537 (comment). Once it does, I will revisit this, but also by extending JavaBuilder.