This message was deleted.

Unclear what the ask is. Toolchains don’t apply to plugins; they are used in tasks that require usage of JVM tooling. Different tasks can use different toolchains if required.

Yes, I was curious about the possibility of using the toolchain APIs outside tasks but I realize that I was asking more for a workaround to solve the problem above rather than a proper solution. Thanks for your answer!

If the ask is about how to ensure the same toolchain is consistently used: you could grab it from

JavaPluginExtension

and use that elsewhere, e.g. set it on an extension of your plugin. Everything is set as a property such that it will be live-updated as needed.

That isn't a problem. The problem I'm trying to solve will probably need to be solved outside Gradle (e.g. using a script). Reading my question again made me realize that was pretty much a dumb question since it's not related to the toolchain APIs

It's not really a dumb question, even with Chris don't grasping it. 😄 But no, as you now recognized, what the plugin needs to operate is the correct JVM to run Gradle with. This is not influencable using toolchains. I usually just let builds that need something other than the Gradle minimum JVM version early in the

pluginManagement

block of the settings script like here: https://github.com/Vampire/setup-wsl/blob/master/settings.gradle.kts#L21-L24 to properly fail early with an understandable error message. What you probably would like to have is in the very far future this: https://github.com/gradle/gradle/issues/2508

I usually just let builds that need something other than the Gradle minimum JVM version early in the

pluginManagement

block of the settings script like here:

This is a good suggestion. Failing early with a clearer message specific to the project makes sense, thanks very much!

What you probably would like to have is in the very far future this:

Yes, that was basically what I meant, thanks for the reference. I understand that removing the need of a pre-installed JDK would be quite a far and big change on the Gradle side since it needs to work in the generic case. For my specific case we can handle this outside Gradle with suboptimal solutions which are specific to that project (e.g. pre-downloading a specific version of the JDK if our minimum requirements are not satisfied). Thanks for your inputs though, surely I'll add the "guard" statement to fail the build fast