Users of Gradle are encouraged to use toolchains to build their projects. A clear advantage of using toolchains is that a project can be built with a pre-defined Java/JDK version, regardless of the JDK a user installed (that is, as long as the Gradle wrapper can be run). For example, if a user installed the JDK 17, they can still build projects targeting Java 21. Moreover, this user can execute the built Java 21 project using gradlew run, despite having an older JDK version installed.
The situation changes as soon as we consider distributions. Say, we have a Gradle project configured with a JDK 21 toolchain for an application called demo. Said user (with the JDK 17) can create a distribution of this project using gradlew installDist. However, as soon as this user tries to run the generated execution script (demo(.bat) from the build/install/demo/bin folder) they end up with a notice that their JDK version isn’t compatible with the byte code they are trying to run.
I understand Gradle wants to make project building as reproducible and as independent of the development environment as possible, hence the support for toolchains. I can also imagine that Gradle wants to provide users with slim, Gradle-less/Gradle-independent distributions of their projects. But why aren’t distributions executed using a toolchain, for example, the toolchain that was required for building the project? After all, without the toolchain, the user that had the JDK 17 installed is still forced to get the JDK 21 to execute the demo distribution.
To put it more generally and practically: can Gradle generate project distributions that can be run regardless of the local version of Java (or perhaps only requiring Java 8)? Can Gradle generate distributions that don’t require a JDK to be installed at all?
is still forced to get the JDK 21 to execute the demo distribution
Not to get it, if he built the distribution, he obviously already has the toolchain, for example at <GRADLE_USER_HOME>/jdks/eclipse_adoptium-21.../jdk-21..., he just has to use it.
The generated distribution does not contain any toolchain.
It is a generic Java distribution according to the write once, run everywhere.
It needs a matching JRE to run like any Java application that does not have a JRE included.
If you include a JRE with the distribution, you make your distribution platform dependent, as it then needs to run on a platform where that shipped JRE is compatible with.
You can of course build such distributions. The JDK even includes the jlink tool with which you can generate a customized JRE with only the modules you actually need for your application so that you don’t need to ship the full JRE.
But there is not yet a functionality built-in to Gradle that can build such a distribution.
So you need to get the JRE you want to ship or build it using jlink yourself and configure the main distribution to inlcude that JRE, and customize the generated start scripts to use that shipped JRE instead of the default lookup logic.
You can also search for a plugin that does all that for you.
There are for example The Badass Runtime Plugin and The Badass JLink Plugin which I used in the past.
Unfortunately, they seem to be unmaintained now, but maybe they can still help you, or maybe you find some replacement for them.
Thanks for your reply and your detailed explanations of creating (platform-dependent) distributions of projects including (parts of) the JRE!
If I understand correctly, we then have two options to distribute our projects:
Ship the bare platform-independent distribution produced by Gradle (with a specific target version of Java).
Create a platform-dependent distribution including a JRE.
That’s too bad because the way Gradle uses toolchains could really offer a third, intermediate option:
Use a wrapper JAR that only requires the JRE 8 to be installed and let it retrieve a toolchain for running the project JAR (that was generated with a higher target version of Java).
I realize it’s not all that difficult to actually use Gradle’s wrapper to create such an ‘intermediate’ distribution, but I hope Gradle will offer this feature in the future. After all, write once, run anywhere only works insofar as users have the JRE installed, and we’re much more likely to find devices with older versions of it than devices with its latest version.
