> It seems that STS should have some level of control over this by setting the JAVA_HOME
> before calling the Gradle tooling api.
At first I thought it is not possible to set JAVA_HOME before calling the tooling API because calling the tooling API is only calling methods in the same process that STS is running. I think setting environment variables only can be done upon launching new processes. With the tooling API, it the API that starts the deamon process. So it the API that is in control of passing anything liken environment variables to that daemon.
However, prehaps you are right. I could maybe try setting the global env parameter via ProcessBuilder.environment... which may affect the daemon process (or any process started by STS for that matter). I'm a bit scared of doing that, because this global setting may also affect other things, not just the gradle deamon. But it is worth a try. I'll post follow up with my findings later.
> Perhaps the problem is with the daemon, and the environment variables are not getting passed?
I am not certain of that, but it seems likely, given bug GRADLE-1757 which is unresolved.
> If we create an external tool profile that runs gradle.bat, everything works fine.
Yes, I would expect so. This because then you are using eclipse launching framework which gives full control over all the parameters passed to the external process, including environment parameters etc. So this can be made to work exactly like you would run Gradle from the commandline. Also in that case you are not running via the deamon.
The tooling API unfortunately affords none of this control and has its own mechanism for running Gradle via the Gradle daemon. In principle it should be the same, but in practice it is not.
> We've tried killing the daemon and changing various installed JDK/JRE settings with no effect.
I don't know what mechanism Gradle uses to determine the Java install it will use the launch the daemon and Java compiler tasks in the build script. So I can't help much there. I'd suggest asking on Gradle mailing lists or forum about this.
However, if I were to guess how it works, I would imagine it consults JAVA_HOME and if this isn't set looks for certain default locations based on your platform. But this is just a guess of course.
What I was suggesting, which is really a very dirty hack, is to try and determine which Java version it actually finds on your machine. When you know which one that is, then make sure that whatever lives at that location is a JDK. Remove the existing JRE install that lives there altogether and replace it with a JDK in the same location. This should work.
I don't like this kind of hackery, but don't really have anything better to suggest, unless Gradle adds some stuff to the tooling API to allow explicititly setting the Java Home passed to the daemon process.
> Perhaps, having the ability to not use the daemon in STS would reveal if that is true, but there is
> currently no way to tell STS not to use the daemon (and maybe you can't through the tooling api, I
> haven't looked into it).
Right, the tooling API doesn't have an option to 'turn off' the daemon.
See also this bug report (not directly related, but has some info about this):