Description of the bug:

When a Java target uses a java_plugin that runs an annotation processor and the --tool_java_language_version is higher than the --java_language_version, the build fails even if --java_runtime_version specifies a JDK version that is at least as high as --tool_java_language_version.

Given that this behavior is already triggered by depending on @bazel_tools//tools/java/runfiles, we experienced this as a regression when migrating to Bazel 6.

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

With this WORKSPACE:

# WORKSPACE

# BUILD
java_binary(
    name = "Main",
    srcs = ["Main.java"],
    main_class = "Main",
    deps = ["@bazel_tools//tools/java/runfiles"],
)

# Main.java
public class Main {
    public static void main(String[] args) {}
}

1. bazel build //:Main passes
2. bazel build //:Main --tool_java_language_version=17 --tool_java_runtime_version=remotejdk_17 fails with Caused by: java.lang.UnsupportedClassVersionError: com/google/devtools/build/runfiles/AutoBazelRepositoryProcessor has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
3. bazel build //:Main --tool_java_language_version=17 --tool_java_runtime_version=remotejdk_17 --java_runtime_version=remotejdk_17 fails with the same error
4. bazel build //:Main --tool_java_language_version=17 --tool_java_runtime_version=remotejdk_17 --java_runtime_version=remotejdk_17 --java_language_version=11 fails with the same error
5. bazel build //:Main --tool_java_language_version=17 --tool_java_runtime_version=remotejdk_17 --java_runtime_version=remotejdk_17 --java_language_version=17 passes

I would argue that the failure in 2. is already unexpected: If the Java language levels in tools can't be higher than that for the target configuration, then what is the purpose of the flag? I always assumed that it exists to allow tooling to use modern Java features while limiting the rest of the codebase to something more compatible (e.g. Java 11).

The failures in 3. and 4. are definitely unexpected: Based on https://bazel.build/docs/bazel-and-java#hermetic-testing, I would have expected JDK 17 to be used for compilation with a -target value of 11 (3.) or 17 (4.). In both cases, the annotation processor compiled for a Java 17 runtime should be runnable. Instead, using --verbose_failures, it looks like remotejdk_11 is still used for compilation.

Which operating system are you running Bazel on?

Linux

What is the output of bazel info release?

6.0.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response