Java toolchains in build.gradle

[gsartori]

Feature description

Since newer Gradle versions (7+) are pushing the Java Toolchains approach as the standard way to manage JDK versions, it might make sense for our templates to adopt that syntax by default.

java {
    toolchain {
         languageVersion = JavaLanguageVersion.of(25)
    }
}

Right now we use:

compileJava.options.release = 25

which works for bytecode targeting but doesn’t guarantee the JDK actually used for compilation, tests, and runtime tasks. Toolchains give us a more consistent and reproducible setup (and automatic JDK provisioning when needed), which feels like a better fit for newbies.

Not a big deal of course, just thought it could be a nice improvement for new apps going forward.

PS: I'm sorry at the moment I don't have bandwidth to make a PR and test it

[jdaugherty]

Toolchains do not let you specify specific versions, they will use whatever minor version is available. As a framework, we're trying to target a minimum version and I suggest for app stability we do not use a toolchain by default. We should leave it as a feature option only.

[jamesfredley]

@gsartori for generated apps and for grails-core, we did have toolchains (since Gradle recommends them by default) this way for ~6 months during Grails 7 development, but then switched to release flags compileJava.options.release = 25

These are the reasons toolchains were not done by default

• Confusing to end users that are not aware of toolchains and expect the app to build and bootrun using the JDK they have specificized for the environment
• Some JDK vendors and versions require adding https://plugins.gradle.org/plugin/org.gradle.toolchains.foojay-resolver-convention
• toolchains override JDK matrix in GitHub workflow

This was just for default, not a hard 1 vs the other or do not use recommendation. Until Gradle 8.14.4 you had to use toolchains to build Grails apps with 25 and I used it extensively.

When toolchains are more widely understood we could possibly revisit, but I think the current state is likely the right default for generated apps for the reasons above.

[gsartori]

I'm not sure I've fully understand your point, my understanding is that compileJava.options.release works with already installed JVMs, it does not try to download a new one if not installed. In both cases we are talking about major JDK versions, not minor ones.

My view on the Grails app template is that it is more of an aid for new projects. I feel like helping newcomers (they may not even have a JDK installed) in a "forge new app" context should be preferred instead of favoring skilled developers or people already working on Grails projects.

[jdaugherty]

@gsartori The issue with toolchains is autodownloads and does not let you specify the specific minor version. We've generally recommended .sdkmanrc as an alternative for this reason. We don't want to suggest default configuration that can cause problems so we generally add it as a forge/profile feature instead.

[gsartori]

@jamesfredley I wrote before reading your post.

@jdaugherty @jamesfredley I see the decision came after experimenting, that sounds good. Yet I still have a feeling in my gut that we are not the target audience for the 'Forge App' feature. That may be the best thing for us but it does not automatically make it the best thing for newcomers. But that might just be me :)