Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
LouisCAD opened this issue Jan 4, 2022 · 4 comments · Fixed by #240

Comments

@LouisCAD
Copy link
Contributor

LouisCAD commented Jan 4, 2022

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

@runningcode
Copy link
Owner

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.

@ChristopherDrum
Copy link

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.

@kenyee
Copy link

kenyee commented May 1, 2023

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...

@ov7a
Copy link

ov7a commented May 3, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants