Hey folks. Weve been using Gradle project level Toolchains to manage Java versions for quite some time and it all works great. We are trying to start using this feature for the Daemon itself, and are encountering a lot of issues on our corporate laptops. All of the issues manifest themselves as issues with PATH. It's not consistent, some people it works great and others it doesn't work at all. I'm wondering if anyone here has much experience with this feature and may be able to chime in here. We are using Gradle 8.14.1 and trying to run Java 21. All of the issues manifest themselves as "cannot run program". We shell out a lot in our Gradle plugins to run things like docker, etc. It seems like for some reason in some situations, the PATH from the parent process is not being passed to the subsequent daemon that gets spun up from the toolchain JDK.

I really wonder whether that might be a red herring. Even without the Daemon toolchain, nowadays you practically always run with daemon, even when using

--no-daemon

which nowadays almost always just means use a fresh one-off daemon and quit it after the build. So I'd imagine that the only difference is, that - if enabled - a toolchain is provisioned if necessary, and the detected or provisioned toolchain then used just like without the system one. I might be wrong of course, not used that feature much so far.

I might be totally off here, but one thing that can happen is that if you are starting a deamon through intellij for example, intellij might pick an incorrect jvm. If you start gradle through the commandline and leave the deamon alive, intelllij will keep on using the correct jvm

Yea we see this behaviour prior to daemon Toolchains specifically when executing through IntelliJ. Every instance of this failing with daemon Toolchains, I've had people restart their machines and do everything CLI driven and no luck. Unfortunately I'm one of the lucky few who have no issues so it's hard for me to dig in on this when it "works on my machine" ;)

intellij might pick an incorrect jvm

On latest versions? Afair they explicitly stated they support the daemon toolchains. Which probably just is using a new enough tooling api client.

so if intellij is at play here: There is an bug somewhere that when gradle is launched through Intellij, gradle will prioritize the jvms incorrectly. For example https://github.com/gradle/gradle/issues/32444 but i have also seen other reports. This is usually workaroundable if you use --stop on the commandline and then execute :help on the commandline. But you could also have a completly different issue

https://www.jetbrains.com/help/idea/gradle.html#gradle_daemon_toolchain

Starting with Gradle version 8.8, IntelliJ IDEA supports the Gradle Daemon toolchain, which helps speed up builds and manage project JDKs. Also, starting with IntelliJ IDEA version 2025.1, this support is available by default.

I kind of remember some bloke from intellij walking in and saying: yes we support toolchains but gradle messes something up and uses JAVA_HOME anyway .. but i cant find the ticket

For the purposes of this question we can ignore IntelliJ outright. I always cut it out of the picture with weird issues like this.

ok than ignore me

Appreciate the input tho!

this ticket? https://github.com/gradle/gradle/issues/30652

Also our CI environments (Jenkins) has no issues like this whatsoever. I am inclined to agree with Vampire that it might be a red herring as these corporate laptops and locked down permissions and corporate proxies have caused us nothing but grief. I just wanted to see if anyone else in the community had any similar experience.

I think i was thinking about this issue: https://github.com/gradle/gradle/issues/32146 but if you are 100% certain tooling API is not at play, its probably not than..

There's no tooling API for sure. It's just any task using project.exec (yes I know it's deprecated, working on it) ends up failing with error messages saying it can't find the commands we want to run.

I just remembered something... are the commands your run also somewhat related to java/ ant for example?

I'd expect tooling api to always be at play. Didn't look into whether this is true, but I'd almost expect that the CLI process is also using the tooling api to drive the daemon. Would wonder if they invented two ways to do it.

Nope. Things like docker, terraform-docs, just random unrelated binaries on the system.

"always" here meaning when the daemon is used which as I said is practically always the case nowadays. 🙂

Yea we use daemon everywhere.

@Andrew Lethbridge linux or windows ?

We're all Mac OS.

Ok support for macos costs extra:P I kind of remember that java can break super weird/hard if you unzip it. There is a strange file that needs to have the executable flag set, otherwise java runs fine but cannot fork any process

Interesting. We do store the JDK in a zip in S3 and use reference it with an HTTPS URL (not using IAM auth to download). Could be something there.

ok so that was many years ago but: inside the lib directory of the jvm there are a few wierd files like jspawnhelper. If these files are missing or are not executeable, then java will run fine but is not able to execute external processes. So affected persons should check if the jvm they are using is able to spawn processes at all