Revert "Use target_compatible_with for Java runtimes"

[jlaxson]

See #17085

d5559c1 changed the JDK definitions used when you specify --java_runtime_version=remotejdk_11 (or other version) so that the toolchains were resolved using target_compatible_with instead of exec_compatible_with. I think that this was not correct because:

1. Semantically, most JDKs compile .class files that can run on any platform. The current form requires you be targeting a platform that has a known-to-bazel JDK.
2. This breaks RBE and cross compilation. Because the toolchains specify only target_compatible_with, bazel will completely disregard the exec platform's OS and other constraints when choosing the appropriate JDK to use.
3. This breaks builds entirely in polyglot repos that have java_library targets. If you accidentally hit that target with a glob when targeting a platform not available in the JDK list, the build fails with a toolchain resolution error. Can't even fix it with target_compatible_with.

Closes #17085

[gregestren]

@cushon can you advise on this?

[cushon]

This change is incorrect.

The target platform is the platform "on which a final output resides and executes".

When building a java_binary, the included JDK needs to be compatible with the target platform, because that's where it will be executed.

Part of the issue here is that the JDK is both a runtime, and a set of tools that can be used during the build. When using the tools from the JDK during the build (e.g. javac), they need to be compatible with the exec platform. The way Bazel approaches this currently is to use a different toolchain to resolve the java_toolchain rule, which provides its own runtime, and uses exec_compatible_with.

[jlaxson]

Thanks @cushon @gregestren

I definitely see how that is how supposed to work, but the commit to be reverted causes all sorts of breakage in RBE and cross-platform builds, I enumerated a few of them in #17085

When building a java_binary, the included JDK needs to be compatible with the target platform, because that's where it will be executed.

Is/was this true for java_test? My experience is that *_test rules exec on the same platform their build toolchain execs on, having nothing to do with the target platform. Then bazel brings the wrong runtime architecture when they get executed. I just added this example to my test repo in #17085.

What sort of changes would address this collection of issues?

[hvadehra]

The files changed here have been moved out of bazel and now reside in @rules_java. If this is still an issue with Bazel 7, please consider opening a PR in that repo.