Unable to advance --tool_java_language_version due to scala_test Runner

[jklukas]

I have a bazel project (currently on Bazel 6.4.0) using rules_scala where we need to produce jars on java language version 8, but we'd like to move up the Java version used for tooling.

So currently in our .bazelrc we have:

build --java_runtime_version=remotejdk_8
build --java_language_version=8
build --tool_java_runtime_version=remotejdk_8
build --tool_java_language_version=8

I tried bumping up the tool versions:

build --java_runtime_version=remotejdk_8
build --java_language_version=8
build --tool_java_runtime_version=remotejdk_17
build --tool_java_language_version=17

Builds are successful but tests fail with the following:

Exception in thread "main" java.lang.UnsupportedClassVersionError: io/bazel/rulesscala/scala_test/Runner 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 52.0

So it looks like the scala_test Runner is compiled based on tool_java_language_version and then used when running tests.

Is it expected that rules_scala requires tool_java_language_version less than or equal to java_language_version? Are there potential workarounds?

For reference, my current interest is to bring the tool jdk up to a level where coverage tools can run as discussed in bazelbuild/bazel#17606.

[jklukas]

With further testing, I see that it's specifically advancing the language version that becomes a problem. The following configuration works:

build --java_runtime_version=remotejdk_8
build --java_language_version=8
build --tool_java_runtime_version=remotejdk_17
build --tool_java_language_version=8

So in this configuration, we're using JDK 17 when compiling the scalatest Runner, but it's compiling using language version 8, which ends up creating a jar that can still be consumed when running tests using JDK 8.

So, the question still stands: is it intended behavior that --tool_java_language_version cannot be higher than --java_language_version when using rules_scala?

I think, for example, this isn't an issue with Java rules because they're using precompiled jars.