Make java.configuration.runtimes machine-overridable

[thakkarparth007]

Potential fix for #2001

I have no idea if changing this configuration's scope can cause unintentional side effects. If so, do educate me and I'd be happy to make some code changes if it is not a lot.

[rgrunber]

After reconsidering, I think this approach might work. Before my main concern was that allowing a project/folder to set java.configuration.runtimes is a security risk in the same way allowing a project to dictate java.jdt.ls.java.home or java.jdt.ls.vmargs would be. But now we have workspace trust, and if we add the property to restrictedConfigurations it should handle that concern.

@testforstephen @fbricon , let me know if there's some case we're missing here.

[testforstephen]

i think it's OK, other than we need to add java.configuration.runtimes as untrusted via restrictedConfigurations.

vscode-java/package.json

Lines 13 to 20 in 083f580

	"capabilities": {
	"untrustedWorkspaces": {
	"supported": "limited",
	"restrictedConfigurations": [
	"java.jdt.ls.java.home",
	"java.home",
	"java.jdt.ls.vmargs"
	]

[Eskibear]

Regarding this, I had a feature request. In java.configuration.runtimes, we store mapping of language level and path to JDK.
Currently I'm unable to use different JDK distribution for different project because the setting scope.

E.g. I have two Maven projects with language level set to Java SE-1.8. But for Project A I want to use RedHat OpenJDK, and Micrsoft's OpenJDK for Project B. Currently I'm not able to do that with workspace level setting.

I'm wondering if we'll have this feature with this PR? Or do we need change something in jdtls, as I remember the backend setting is also per machine.

[rgrunber]

Regarding this, I had a feature request. In java.configuration.runtimes, we store mapping of language level and path to JDK. Currently I'm unable to use different JDK distribution for different project because the setting scope.

E.g. I have two Maven projects with language level set to Java SE-1.8. But for Project A I want to use RedHat OpenJDK, and Micrsoft's OpenJDK for Project B. Currently I'm not able to do that with workspace level setting.

I'm wondering if we'll have this feature with this PR? Or do we need change something in jdtls, as I remember the backend setting is also per machine.

I just tried out the PR and it allows me to override java.configuration.runtimes from .vscode/settings.json in a workspace folder. It seems in line with what https://code.visualstudio.com/api/references/contribution-points implies about machine-overridable.

I couldn't set a folder-specific setting on the client for a multi-root workspace, and get it to be sent to the language server, but maybe I'm not understanding how the setting should work. The problem I see is I don't think we even support a multi-root project. In JVMConfigurator, we call JavaRuntime.setDefaultVMInstall(..) to set the JVM, which says :

Sets a VM as the system-wide default VM, and notifies registered VM install

So this would only work with a single "project" per workspace.

[Eskibear]

So this would only work with a single "project" per workspace.

I think that's fine for me. I can always open different projects in different workspace for the moment.

But in Eclipse, when I import multiple projects, I can configure VMInstall per project. So I think it's at least feasible regardless of effort. In long-term plan, I believe we do want to fully support multi-root workspace, maybe we should think about how to refactor the JVMConfigurator then.

[rgrunber]

So this would only work with a single "project" per workspace.

I think that's fine for me. I can always open different projects in different workspace for the moment.

But in Eclipse, when I import multiple projects, I can configure VMInstall per project. So I think it's at least feasible regardless of effort. In long-term plan, I believe we do want to fully support multi-root workspace, maybe we should think about how to refactor the JVMConfigurator then.

Yup! The JDT API definitely has some way to set the JVM per project. We've likely only used the global setting for now. As long as we're fine with some functionality being unsupported for the time being, I think it should be fine to proceed with this.

@thakkarparth007 , can you update the PR based on #2337 (comment)

[thakkarparth007]

@rgrunber done.

[rgrunber]

If there's no opposition to this, or special case we've missed, I'll merge soon. Last remaining thing is to update https://github.com/redhat-developer/vscode-java/wiki/JDK-Requirements to briefly mention workspace settings can now take advantage of the setting.