gradle-doctor icon indicating copy to clipboard operation
gradle-doctor copied to clipboard

Gradle internally infers inexact JAVA_HOME, leading to the "Gradle is not using JAVA_HOME" error.

Open LouisCAD opened this issue 3 years ago • 4 comments

Hello!

Firstly, I wish you a happy New Year, and I hope you're doing well!

I'm hitting a wall as I'm using it in combination with SDKMAN regarding the Java home check.

I did some investigation to understand what's going on, and it looks like Gradle is resolving what it believes is the java home to a different directory than the actual JAVA_HOME environment variable on macOS:

| Gradle is not using JAVA_HOME.                                                                       |
| JAVA_HOME is /Users/me/.sdkman/candidates/java/current                                         |
| Gradle is using /Users/me/.sdkman/candidates/java/17.0.1.fx-zulu/zulu-17.jdk/Contents/Home

The /Users/me/.sdkman/candidates/java/current file is a symlink that points to /Users/me/.sdkman/candidates/java/17.0.1.fx-zulu, which is different from /Users/me/.sdkman/candidates/java/17.0.1.fx-zulu/zulu-17.jdk/Contents/Home shown in the last line of the error message snippet I pasted just above.

It seems like SDKMAN has a double symlink for some parts of the JDK, and Gradle follows the symlink of some of these files, and then considers the parent directory of these files to be the java home, making the comparison on the directory fail in Gradle Doctor.

Judging from Gradle Doctor source code, the latter incorrect value is returned by Jvm.current().javaHome from the org.gradle.internal.jvm.Jvm internal package.

Just below, you can see the Java home I'm using is made out of symlinks, which all point to sub-directories of Contents/Home:

Screenshot 2022-01-04 at 22 58 16

This puts me in an uncomfortable situation as I have to disable the Java home check, and I cannot rely on it to ring the bell if the Gradle JVM actually ends up changing again, unless I remember to enable it from time to time and check the output, ignoring the case where it's a symlink issue.

Do you know if there's a way to get the actual java home directory from Gradle APIs, or if Gradle doctor would need to do the same trick that Gradle does to land on the same final java home, after symlinks being followed through via a target file (which I guess is the java executable from the bin directory)?

Thanks in advance, all the best!

Louis CAD

LouisCAD avatar Jan 04 '22 22:01 LouisCAD

Thanks for filing this detailed bug! I don't know of a way to get the actual home directory from the Gradle APIs. It is certainly not part of the public API. It is likely that the Gradle Doctor would need to do the same trick that Gradle does.

runningcode avatar Jan 05 '22 12:01 runningcode

Came in to see if this issue has been reported yet or not. I'm +1' ing on this, because even though JAVA_HOME is set properly, the gradle doctor check can't resolve it and I'm pretty much locked out of using this tool. I've tried overriding $JAVA_HOME, as set by sdkman, and the best I can get it to spit out is

JAVA_HOME is /Users/christopher.drum/.sdkman/candidates/java/11.0.13-zulu
Gradle is using /Users/christopher.drum/.sdkman/candidates/java/11.0.13-zulu/zulu-11.jdk/Contents/Home  

which is correct, and is the same Java, but not good enough to pass the check.

ChristopherDrum avatar Apr 01 '22 02:04 ChristopherDrum

FWIW, this only happens w/ the Zulu JDK...others like Temurin (aka Adoptium) and GraalVM do not have this issue because only Zulu has this convoluted symlink structure...

kenyee avatar May 01 '23 18:05 kenyee

For the context, Gradle determines the equality of java homes here

ov7a avatar May 03 '23 08:05 ov7a