Fix build JDK version check to match documentation

[sirhcel]

The current documentation at https://badass-runtime-plugin.beryx.org/releases/1.13.0/ states:

The plugin requires Java 11 and Gradle 7.0 or newer. [...]

Building with JDK 17 actually works.

[sirhcel]

Fixed faulty condition working by accident when committing late. Thank you for spotting this @srehlig!

[hakanai]

A common pitfall you might want to check is to build on JDK 17 and make sure the jar that comes out is still JDK 11 compatible. Just in case this project has just let Gradle choose the target version...

[janosvitok]

A common pitfall you might want to check is to build on JDK 17 and make sure the jar that comes out is still JDK 11 compatible. Just in case this project has just let Gradle choose the target version...

This may be useful: https://docs.gradle.org/current/userguide/toolchains.html and this https://blog.gradle.org/java-toolchains

As I understand it, the targetCompatibility should be defined to make sure the bytecode is compatible with JDK 11 or whatever is selected (when compiling under higher version. Toolkits should take care of this better.

FWIW, I tried to compile under JDK 21 (temurin, macos):

• I had to upgrade gradle to 8.5
• compilation when fine with this change
• RuntimePluginSpec tests failed due to gradle 7.x not understanding java 21 (java.lang.IllegalArgumentException: Unsupported class file major version 65)

[sirhcel]

A common pitfall you might want to check is to build on JDK 17 and make sure the jar that comes out is still JDK 11 compatible. Just in case this project has just let Gradle choose the target version...

I'm controlling the build output in my project from build.gradle with:

sourceCompatibility = 1.8
targetCompatibility = 1.8

The original version of the check I'm addressing prevents me from using the plugin with a newer JDK at all.

Or is the documentation meant to read as (requires JDK 11) and (Gradle 7.0 or newer)?

[hakanai]

Oh, I meant in this project. The plugin project itself, as opposed to the project where you're using the plugin.

Because if some future maintainer ran the build on JDK 17, you wouldn't want them inadvertently publishing jars which can only be used on JDK 17. Some people using this plugin would expect it to work with JDK 11 still.

If it turned out that JDK 17 cannot build jars which are compatible with JDK 11 - then yeah, you'd want to update the docs instead. (I vaguely remember that it can do it, but I haven't tried it myself.)