rules_java bootstrap_runtime_toolchain_type: condition on java_language_version instead of java_runtime_version?

[rbeasley]

When compiling for Java N, one must use the same boot classes from JDK N. Failing to do that will allow Java N+ types to leak into the code such that it will compile but later fail at runtime. Using the example from Baeldung's A Guide to Java Source and Target Options (snippet reproduced below), this will successfully compile with --java_language_version=8 even though List.of didn't appear until Java 9. Only by specifying --java_runtime_version=8 will I encounter the (desired) cannot find symbol error.

import java.util.List;

public class TestForSourceAndTarget {
  public static void main(String[] args) {
    System.out.println(List.of("Hello", "Baeldung"));
  }
}

Bazel's Java rules are sensitive to three different toolchain types (reference):

• @bazel_tools//tools/jdk:toolchain_type
• @bazel_tools//tools/jdk:runtime_toolchain_type
• @bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type

A toolchain of bootstrap_runtime_toolchain_type is an input to the bootclasspath rule. Boot classes are extracted from that toolchain. Today, the toolchain is selected based on a match of the java_runtime_version CLI option (ref, see target_settings).

Should bootstrap_runtime_toolchain_type bind to java_language_version instead? Doing so would constrain boot/platform classes to a project's Java language version and guard against the situation described above.

[danukarangith]

compiling for Java N, it is important to use the boot classes from JDK N to prevent Java N+ types from leaking into the code, which can lead to compilation success but runtime failures.

[fmeum]

Cc @hvadehra @cushon

[cushon]

Should bootstrap_runtime_toolchain_type bind to java_language_version instead?

Yes, that sounds right to me, thanks for raising this and the writeup.

In general I'd recommend configuring --java_runtime_version= to match the runtime that the code is deployed to, so e.g. if you want Java 8 compatible code and configure --java_language_version=8 --java_runtime_version=8 that should work correctly even with the current behaviour.

But the proposed change is safer, and it can be useful to have configurations like --java_language_version=8 --java_runtime_version=11 to start testing a new runtime version before adopting new language features, and while still being able to deploy to JDK 8.

[fmeum]

The only downside I see with this is that --java_language_version doesn't offer a way to select the particular flavor of JDK (e.g. the local one) to extract the bootclasspath from.

[fmeum]

I prototyped this as an incompatible flag for rules_java over at bazelbuild/rules_java#182. Instead of matching on --java_language_version directly, which has the issue described in #21769 (reply in thread), I am using a transition to combine --java_language_version (say 11) and --java_runtime_version (say remotejdk_21) into the name of the bootstrap runtime (in this case remotejdk_11).

Please let me know what you think.