search

beryx / badass-runtime-plugin

Create a custom runtime image of your non-modular application
https://badass-runtime-plugin.beryx.org
Apache License 2.0
161 stars 21 forks source link

Fix build JDK version check to match documentation #148

Open sirhcel opened 9 months ago

sirhcel commented 9 months ago

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 commented 9 months ago

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

hakanai commented 9 months ago

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 commented 8 months ago

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):

sirhcel commented 8 months ago

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 commented 8 months ago

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.)