3.16.2 ignores java.import.gradle.java.home

[MetricMike]

1554 broke JDK detection when starting the Gradle Server.

Before, it would honor java.import.gradle.java.home if set and at or above the required version (currently 17). https://github.com/microsoft/vscode-gradle/blob/5763213413b9e03fd60819e5588542236e5fb069/extension/src/server/serverUtil.ts#L30-L33

After, it will select the embedded JRE from the redhat.java extension when present. https://github.com/microsoft/vscode-gradle/blob/55e3b9653d39967fc1fa76f82b117dad8882f45b/extension/src/server/serverUtil.ts#L24

Please revert this breaking change and respect user configuration when set.

[jdneo]

Hi @MetricMike,

The jdk we are searching here is just used to launch the gradle server, and is not used to import and run gradle task via gradle tooling api.

Ideally, java.import.gradle.java.home should be used to do those stuff.

If it's not the case, we need to fix it.

Could you please give more information about this issue? Like, a sample project.

[MetricMike]

Thank you so much for the quick response!

Using Spring Initializer to create a brand/new repo on https://github.com/MetricMike/example_vscode_1589:

The output from Gradle for Java with 3.15.0 installed is:

[info] [gradle-server] Server started, listening on 36825
[info] Gradle client connected to server
[info] Java Home: /home/metricmike/.asdf/installs/java/adoptopenjdk-21.0.4+7.0.LTS
[info] JVM Args: --add-opens=java.base/java.util=ALL-UNNAMED,--add-opens=java.base/java.lang=ALL-UNNAMED,--add-opens=java.base/java.lang.invoke=ALL-UNNAMED,--add-opens=java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens=java.base/java.nio.charset=ALL-UNNAMED,--add-opens=java.base/java.net=ALL-UNNAMED,--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED,-XX:MaxMetaspaceSize=384m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=UTF-8,-Duser.country,-Duser.language=en,-Duser.variant
[info] Gradle User Home: /home/metricmike/.gradle
[info] Gradle Version: 8.8
[info] Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

The output from Gradle for Java with 3.16.4 installed is:

[info] [gradle-server] Gradle Server started, listening on 33113
[info] Gradle client connected to server
[info] Java Home: /home/metricmike/.vscode-server/extensions/redhat.java-1.33.0-linux-x64/jre/17.0.11-linux-x86_64
[info] JVM Args: --add-opens=java.base/java.util=ALL-UNNAMED,--add-opens=java.base/java.lang=ALL-UNNAMED,--add-opens=java.base/java.lang.invoke=ALL-UNNAMED,--add-opens=java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens=java.base/java.nio.charset=ALL-UNNAMED,--add-opens=java.base/java.net=ALL-UNNAMED,--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED,-XX:MaxMetaspaceSize=384m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=UTF-8,-Duser.country,-Duser.language=en,-Duser.variant
[info] Gradle User Home: /home/metricmike/.gradle
[info] Gradle Version: 8.8
[info] Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

After setting java.import.gradle.java.home on Ubuntu 24.04/WSL2

...
"java.import.gradle.java.home": "/home/metricmike/.asdf/installs/java/adoptopenjdk-21.0.4+7.0.LTS",
...

[debug] Refreshing tasks
[debug] [gradle-server] Gradle Server cmd: /home/metricmike/.vscode-server/extensions/vscjava.vscode-gradle-3.16.2024081608/lib/gradle-server "--port=33319" "--startBuildServer=true" "--languageServerPipePath=/run/user/1000/206f5bae6fdbeafed174664f90dadb67.sock" "--pipeName=/run/user/1000/ed346ecdb01785f50100d9a67160ca7e.sock" "--bundleDir=/home/metricmike/.vscode-server/extensions/vscjava.vscode-gradle-3.16.2024081608/server"
[info] [gradle-server] Gradle Server started, listening on 33319
[info] Gradle client connected to server
[info] Java Home: /home/metricmike/.asdf/installs/java/adoptopenjdk-21.0.4+7.0.LTS
[info] JVM Args: --add-opens=java.base/java.util=ALL-UNNAMED,--add-opens=java.base/java.lang=ALL-UNNAMED,--add-opens=java.base/java.lang.invoke=ALL-UNNAMED,--add-opens=java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens=java.base/java.nio.charset=ALL-UNNAMED,--add-opens=java.base/java.net=ALL-UNNAMED,--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED,-XX:MaxMetaspaceSize=384m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=UTF-8,-Duser.country,-Duser.language=en,-Duser.variant
[info] Gradle User Home: /home/metricmike/.gradle
[info] Gradle Version: 8.8

My environment (at home, Ubuntu 24.04 WSL2 instance) has JAVA_HOME set:

WSL at     ...  example_vscodegradle_1589  main  0.636s                                                                                                                                                              metricmike / mtowerwsl  23:53:25 
❯ echo ${JAVA_HOME} 
/home/metricmike/.asdf/installs/java/adoptopenjdk-21.0.4+7.0.LTS

The specific case I mentioned (not reproduced here) was on a CentOS7 machine whose JAVA_HOME pointed toward a Java18 JDK.

When I specify java.import.gradle.java.home on my Ubuntu 24.04 WSL2 instance at home, things seem to work as expected (Gradle Server using the JDK I specify, not the embedded redhat JRE).

I'll continue to try to narrow down the differences, but I am disheartened by the "just used to launch the gradle server" assertion. The debug output provided by this extension is not clear about how the extension determines which JDK to use - the PR I linked seems definitive that configuration settings are ignored, yet when trying to reproduce at home that doesn't seem to be the case. The only clue I have to lean on is a PR.

[jdneo]

Did you set java.import.gradle.java.home on your CentOS7?