chore: avoid Java version mismatch (alternative)

[nielspardon]

Here's an alternative to #433 which requires less changes.

Mainly:

• the Jabel plugin handles some of the differences between Java 17 and Java 8
• some APIs are not available in Java 8 and Jabel does not handle them (we don't have to change anything if we would use release level 11)
• configures both the Java and the Scala compiler to compile to release level 8
• configures the compiler version to be Java 17
• configures the JVM used for test execution to be Java 8

Downside of the approach is that we are still relying on Jabel to enable a subset of the newer Java syntax to be compiled by the Java compiler to Java 8 compatible bytecode while especially for Java API changes like List.of(), Set.of(), Map.of() and a couple others we need to write code that only uses the APIs available in Java 8.

[bestbeforetoday]

This change uses within the same task both of these options:

sourceCompatibility = "17"
options.release = 8

The Java 17 javac spec says:

Note: When using --release, you cannot also use the --source/-source or --target/-target options.

Mixing these options (along with targetCompatibility and using Jabel) is the reason for the build issues addressed by #433. Changing the spark module from targeting Java 17 to target Java 8 is an additional change outside of the scope of that PR.

[nielspardon]

Mixing these options (along with targetCompatibility and using Jabel) is the reason for the build issues addressed by #433.

I don't think using Jabel caused the build issues I saw it may have contributed to them. The build issues I saw were coming from the Gradle toolchain plugin which was trying to interpret the faulty Gradle configuration and non deterministically picked a JVM that it thought was the best choice.

I wasn't aware of Jabel before looking at your PR which led me to investigate how Jabel was supposed to be used which made me aware of some differences in the way substrait-java currently configures the Gradle toolchain vs what the Jabel readme recommends.

https://github.com/bsideup/jabel?tab=readme-ov-file#gradle-7-and-newer

As I stated in the description of this PR above it still relies on Jabel which comes with its own challenges and potential build issues.

EDIT: The sourceCompatibility line mainly exists since I wanted to be as close as possible to the Jabel recommended configuration to rule out that we are missing something that was intended by the Jabel authors. The code would work without this line.