chore: avoid Java version mismatch

[bestbeforetoday]

When developing, the build (both on the command-line and in the IDE) frequently fails due to usage of unsupported Java language features for the target Java runtime. This is due to the the Java source version being set to a newer version than the target Java version. While this sometimes works, this combination is explicitly disallowed by the Java compiler. Source version must be equal to or less than the target version.

This change uses the correct Java toolchain version for each sub-project. The exception being the core sub-project, since it targets Java 8 whereas ANTLR requires Java 11+ to run. Instead, the Java compiler release option is set to Java 8, ensuring that Java 8 bytecode is produced and that no APIs not present in Java 8 are used.

While numerous code changes are required to adhere to the target Java language version, there are no functional changes.

[vbarua]

Took a quick skim, and I'm broadly on-board with these changes. If you can fix the conflicts introduced by #427, I can prioritize this PR to avoid future conflicts.

Do we still need to keep the various Jabel plugins around after this?

[bestbeforetoday]

I have rebased on the new commit and resolved the merge conflicts. I have removed the Jabel usage too — I hadn't noticed that before!

The failing build checks look to be caused by vulnerabilities in the Calcite's dependency tree. I'd prefer not mix any changes to address that into this PR.

[nielspardon]

The failing build checks look to be caused by vulnerabilities in the Calcite's dependency tree.

I created #442 for the vulnerability

[bestbeforetoday]

Rebased and resolved merge conflicts again.

[bestbeforetoday]

@vbarua I have added a second commit that configures a Java 17 toolchain for only the Isthmus tests, and reverting (almost) all of the changes to the Isthmus unit test code to make it compliant with Java 11. This allows the use of text blocks in the unit tests while maintaining strict Java 11 compliance for the main code.

Just be warned that — for me at least — this seems to make VS Code very unhappy since it still expects the test code to be Java 11. Intellij seems to deal with it OK. It is likely to cause problems for some users though.

Let me know if you want me to remove this change, or to make similar changes to any of the other test components.

[vbarua]

@bestbeforetoday

Just be warned that — for me at least — this seems to make VS Code very unhappy since it still expects the test code to be Java 11.

Let's undo that commit. I can live without multi-line strings, and I'd rather focus on making sure the development experience is good, which is the whole point of this change in a lot of ways.

[bestbeforetoday]

@vbarua I have reverted to last commit so this change is back at the state where a consistent toolchain (matching the target release bytecode version) is used for each sub-project.

[nielspardon]

I am anyway a fan of using explicit types instead of the var keyword so most of the changes to core I prefer.

Losing multi-line strings and the new instanceof syntax is unfortunate.

I'm wondering whether the release level for the spark module should also be Java 8 ort 11 instead of 17 given that apparently a significant number of Spark users are on old Java versions.

I'm also wondering after looking into what jabel is supposed to do whether there is a better approach than rewriting so much code.

[nielspardon]

I'm also wondering after looking into what jabel is supposed to do whether there is a better approach than rewriting so much code.

I played a bit with it and came up with this alternative: #443

[bestbeforetoday]

Rebased on latest main branch content.

[vbarua]

Thanks for working on this. I'm going to miss having nice things, but I'm not going to miss Jabel.