-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
Comments
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. |
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
which is correct, and is the same Java, but not good enough to pass the check. |
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... |
For the context, Gradle determines the equality of java homes here |
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:
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 theorg.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
: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 thebin
directory)?Thanks in advance, all the best!
Louis CAD
The text was updated successfully, but these errors were encountered: