redhat-developer / vscode-java

Java Language Support for Visual Studio Code
Eclipse Public License 2.0
2.07k stars 427 forks source link

Define several runtimes for a same version of Java #2115

Open Nicryc opened 2 years ago

Nicryc commented 2 years ago

Is it possible to define several runtimes for a same version of Java in VSCode? I'd like to use the both the Hotspot and OpenJ9 JVM.

My java.configuration.runtimes setting in VSCode looks like this:

"java.configuration.runtimes": [
    {
        "name": "JavaSE-1.8",
        "path": "C:\\Program Files\\Eclipse Foundation\\jdk-8.0.302.8-hotspot"
    },
    {
        "name": "JavaSE-11",
        "path": "C:\\Program Files\\Eclipse Foundation\\jdk-11.0.12.7-hotspot"
    },
    {
        "name": "JavaSE-16",
        "path": "C:\\Program Files\\Eclipse Foundation\\jdk-16.0.2.7-hotspot"
    }
],

I also have other JVMs installed for each of these Java version on my machine. For example one of them is located here: C:\Program Files\Semeru\jdk-8.0.302.8-openj9.

Environment
rgrunber commented 2 years ago

I don't think this is supported because the idea is to detect the target environment that the project requires (eg. Maven project defines source/target of 11) and use the corresponding JVM for that. If there were multiple, then we would need to prompt each time to clarify which is actually intended in that case.

I believe https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack provides a UI over java.configuration.runtimes that makes it a bit easier to modify these options. See https://github.com/redhat-developer/vscode-java/issues/2001#issuecomment-870187334 for a rough idea.

rgrunber commented 2 years ago

In https://github.com/redhat-developer/vscode-java/issues/2001, we allowed projects to set their own java.configuration.runtimes . This allows having different runtimes for a particular Java version across projects. Not exactly what is requested here, but a step in that direction.

jdneo commented 5 months ago

Allowing multiple jdk installation paths for the same environment name in our setting schema can be helpful. Because we cannot guarantee that the jdk scan logic can always find all jdk installations. If java.configuration.runtimes allows configure multiple JDKs for the same environment. User can set those JDKs at global level then this information can be shared across all workspaces.

Why not just registering all user set JDKs to the registration? In the case that there are multiple JDKs maps to the same environment, it is not necessary to use the environment name as the JDK name, we can generate a unique name for it.