Windows 10 OS. I'm using a Cygwin BASH console to run Gradle.
I've been struggling with this for a few hours now. There are one or two questions on SO which seem to relate this but I'm still a long way from understanding the basic mechanisms and how to get Gradle to use the right JDK/JRE.
This started earlier when gradle build didn't work and complained that it couldn't find "tools.jar". This appears to be a sign that the path to the Java JRE used to run the Gradle app isn't associated with a JDK. This is indeed the case: the JRE it insists on using to start up is at "C:\Program Files\Java\jre1.8.0_73\". This is a JRE without a JDK.
The JDK I want Gradle to use is at "D:\apps\Java\jdk1.8.0_191\".
I have set JAVA_HOME to this value. I have also placed "D:\apps\Java\jdk1.8.0_191\bin\" at the very start of the PATH environment variable.
In both Cygwin and the W10 console, when I go "java -version" it prints out the 1.8.0_191 version, proving that the OS System is configured as expected.
But Gradle itself insists on using the JRE in C:.
I tried numerous experiments and rebooted numerous times.
When I went, in build.gradle:
println "java.home is ${System.properties['java.home']}"
... it always printed out the C:\ location version (1.8.0_73)
Finally I made this impossible by renaming "C:\Program Files\Java\" to "C:\Program Files\JavaXXX\". This then gives:
Chris@M15B /cygdrive/d/My Documents/software projects/EclipseWorkspace/LuceneIndexer_3
$ gradle build Error: could not open `C:\Program Files\Java\jre1.8.0_73\lib\amd64\jvm.cfg'
So it appeared, as far as I could surmise, that something inside Gradle has got its heart stubbornly set on using a particular JRE location... which disregards the JAVA_HOME variable, the PATH entries and the OS's own understanding of which JDK/JRE should be used... and even sets System setting java.home to a "spurious" setting (or one I don't want to use).
Finally... I put this line in gradle.properties:
org.gradle.java.home=D:\\apps\\Java\\jdk1.8.0_191
When I then changed "C:\Program Files\JavaXXX\" back to "C:\Program Files\Java\", finally the thing built properly. And finally java.home was printed out as "D:\apps\Java\jdk1.8.0_191". But when I again renamed to "C:\Program Files\JavaXXX\" the "could not open" error returned. In other words, even if you can configure java.home in Gradle, Gradle itself appears to be reliant on a version of Java that you don't want it to use, and which is not the version for which the OS is configured!
How on earth does the Gradle application find the JRE it is going to use to do its business? Surely there must be a way to get it to use another one?
later
I also tried adding some ECHO statements to the gradle startup script... in which there is a specific section devoted to determining the JVM to use. These experiments showed clearly that this script is correctly using the desired JDK (under D:). Nor can it be a Cygwin-related problem, as other Cygwin commands work fine when Java\ is renamed to Java_XXX. I also examined the registry: no clues found.
By going "gradle" at the Cygwin command prompt, something somewhere in the works insists on using a baked-in JRE location, even before the gradle startup script is run...
I was able to resolve this by upgrading my system's Java and Gradle. I changed to Java 9 (although apparently we're on Java 11 at the time of writing). I also changed to Gradle 5.2.1 (from 3.5). I think I concluded that Gradle 3.5 was incompatible with Java 9...
I was quite confused: for a moment it appeared that Cygwin was out of date and that I needed a newer version of its Gradle. But in fact Cygwin was inheriting PATH from W10, and one of those PATH entries was "%GRADLE_HOME%\bin". Cygwin was using the W10 Gradle. What fun to be using a Windoze OS!
GRADLE_HOME (different from GRADLE_USER_HOME, where dependencies are downloaded!) thus had to be changed to the location of the new version of Gradle.
All sorts of funny consequences followed for Eclipse: the dreaded red exclamation marks... caused by the fact that under "Project and External Dependencies" for several projects the dependencies revealed themselves to be located in the old 3.5 GRADLE_USER_HOME location, which I had renamed deliberately to make it inaccessible. I found no way to "rebuild" these dependencies in Eclipse (i.e. to force use of GRADLE_USER_HOME, now pointing to a location under ...5.2.1), and instead opted to recreate the Eclipse projects.
Quite trying. There must of course be a better way.
Incidentally, it does indeed appear that when you run a Gradle command in Cygwin the JVM as configured for your OS in the "Java Control Panel" gets invoked before the gradle startup script is run (... I think). Even if your JAVA_HOME setting and first PATH entry are pointing to a different JRE (which they probably shouldn't be).