VSCode java home not being used

[skypartan]

Extension Name: vscode-gradle
Extension Version: 2.4.13
OS Version: Windows 1909
VSCode version: 1.43.2

Describe the bug
The extension doesn't use the java environment set in the workspace settings, instead it defaults to gradle search method, which uses the default system installation.

To Reproduce
Have a system with multiple versions of java (8 and 11 in my pc)
Configure one of them as the default (JAVA_HOME or System Path)
Configure vscode to use the other version with "java.home" setting (provided by Java extension from Red Hat)

Expected behavior
All Gradle tasks should be executed with the java version configured in the vscode "java.home" setting.

Does the bug still exist if you disable all other extensions?
Yes

[badsyntax]

Hi. Thanks for the report. Yes this extension does not read any of the settings that are defined by the vscode-java extension. (Full list of settings here.)

Instead this extension uses a more standard approach of defining per-project java settings, that can be defined in gradle.properties, or via environment variables like JAVA_HOME which can be set in the project workspace settings, for example: #243 (comment) (You can also use a tool like direnv to set project specific environment vars.)

I understand the confusion the vscode-java settings can cause here. I am considering to read those settings within this extension, but I am not fully convinced it's a good idea yet.

[skypartan]

Hi. Personally I think it makes sense to use vscode-java settings, mainly because it's the way to go for java development in VSCode, so you can basically assume that it is installed with this extension.

For the gradle.properties file, I don't think it is the best place for this type of configuration. The gradle's documentation says that it should be added to VCS which means it cannot store single user's configuration, because these will change from developer to developer since each one might have a different working environment.

As for the environment variables, it works, but feels more like an workaround than an actual solution.

[badsyntax]

Hey thanks for responding.

I agree with your first point.

For the second point, yes the point of gradle.properties being added to VCS is to provide a consistent environment for everyone working on the project. I do agree that org.gradle.java.home is something that could be different on different machines though.

About the environment variables, I feel this is the most consistent & standard way of configuring things. Developers will already be aware of these standard variables. Maybe it's not obvious to some how to change those variables on a per-project basis, but that's outside the scope of this extension.

But saying all of that, I think consistency is more important here. So if the vscode-java authors decided to control java configuration using non-standard vscode settings, then I should do the same, to provide better compatibility.

You've basically convinced me to a least support java.home 😃I am unsure about supporting other settings though (eg java.import.gradle.jvmArguments) as those settings imply they are only used for synchronizing gradle projects via buildship (which is used by the language server). I will think about this some more. But for now, I will make a change to support java.home.

[skypartan]

That's great! I think it will simplify some of the initial work of setting up projects. Thanks for the help, and the extension!

[badsyntax]

Cool 👍 Thanks for the feedback.

Some initial ideas about providing support for this setting:

Similar to vscode-java I will need to start the gradle server using java.home. Unlike vscode-java, I start this process using a shell script generated by CreateStartScripts. I will need to maybe use a custom start script template and provide java.home as either a custom ENV var or an argument to the start script to launch the server.

I'm unsure if i also need to specify this setting on the gradle ModelBuilder but if so I will need to either create a new argument for the server or read from custom ENV var as above, and make that value accessible so the handlers can read it.

[badsyntax]

I've got a working solution with #255

I've not being able to write tests for this (testing vscode extensions are hard) but I have verified it's working as expected by looking at the spawned java processes.

(Also sorry for the delay, due to the corona virus and various other reasons, it took me a long time to setup a windows VM to test the changes to the windows .bat startup script.)

I will release shortly so you can test this.

[badsyntax]

@skypartan this feature is now released with version 2.5.0

can you update the extension and see if this works for you?

i've added a note about this setting to the README here: https://github.com/badsyntax/vscode-gradle#extension-settings

[skypartan]

Hey! I did a quick test here and it looks like it's working without errors, my tasks were executed with the jdk defined in settings.json. Thanks!

[badsyntax]

Good to hear, thanks!

Refs: microsoft/vscode-java-pack#347 (comment)