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?

[MetricMike]

I no longer have CentOS7 instances in my work, but I'm still observing this behavior in the RHEL8-family (e.g., Rocky).

While the Redhat Embedded JRE is suitable in most cases, this extension should revert to its previous behavior of respecting user choice in the JVM required to run it.

[zerodegress]

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.

In fact, always using the built-in jre may result in errors that require a lower version of gradlew to run, and I'd still like to be able to roll back to the original behavior.

for example:

[info] Java Home: /home/user/.vscode-oss/extensions/redhat.java-1.42.0-linux-x64/jre/21.0.7-linux-x86_64
[info] JVM Args: --add-exports=java.base/sun.nio.ch=ALL-UNNAMED,--add-opens=java.base/java.lang=ALL-UNNAMED,--add-opens=java.base/java.lang.reflect=ALL-UNNAMED,--add-opens=java.base/java.io=ALL-UNNAMED,--add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED,--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.base/java.util=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=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,-Xmx2048M,-Dfile.encoding=UTF-8,-Duser.country=CN,-Duser.language=zh,-Duser.variant
[info] Gradle User Home: /home/user/.gradle
[info] Gradle Version: 7.2
[error] FAILURE: Build failed with an exception.

* Where:
Initialization script '/tmp/4f5c6f29ec59976f766c05ce58955aab2ed6151d8274b699e654922857bc1877.gradle'

* What went wrong:
Could not compile initialization script '/tmp/4f5c6f29ec59976f766c05ce58955aab2ed6151d8274b699e654922857bc1877.gradle'.
> startup failed:
  General error during conversion: Unsupported class file major version 65
  
  java.lang.IllegalArgumentException: Unsupported class file major version 65
       ...
  	at java.base/java.lang.Thread.run(Unknown Source)
  
  1 error


* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

CONFIGURE FAILED in 105ms
[error] Error getting build for /home/user/termux-app: Could not run build action using connection to Gradle distribution 'https://services.gradle.org/distributions/gradle-7.2-all.zip'.
[error] [gradle-server] Could not run build action using connection to Gradle distribution 'https://services.gradle.org/distributions/gradle-7.2-all.zip'.

[RD-1-2020]

Hello everyone!

I encountered a similar problem on Windows 11.

This config helped me fix it. Maybe this will help.

Screenshot

[github-actions[bot]]

Hi @MetricMike, I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

Suggestions

• Workaround: pin the Gradle extension to version 3.16.1 to restore the previous JDK‐selection behavior.
• Override the embedded JRE by setting the Java extension’s java.jdt.ls.java.home (e.g. in your User or Workspace settings) so that the Red Hat Java extension—and transitively the Gradle extension—uses your specified JDK:
  https://code.visualstudio.com/docs/java/java-project#_java-home-configuration
• Switch the Gradle extension to use the VS Code Java Extension API for JDK resolution, as discussed in issue #1173: • Title: Use VsCode Java Extension API to get project JDK
  • URL: https://github.com/microsoft/vscode-gradle/issues/1173
  • This API exposes RequirementsData.java_home, which can be used to detect the project JDK in a forward-compatible way.

Labels

• bug

The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!