Update jdk and old workspace still points to the stale JRE system libraries

Steps to reproduce:

Install jdk1.8.0_131 in windows 10, and set JAVA_HOME and Path environment variables.
Install latest vscode-java extension in vscode, and open a java 8 maven project.
F12 at java.io.PrintStream.println, jump to editor contents/rt.jar/java.io/PrintStream.class.
Install the latest jdk-9.0.1 and update JAVA_HOME and Path environment variables.
Restart vscode window.
F12 at java.io.PrintStream.println, still jump to the stale jre source contents/rt.jar/java.io/PrintStream.class. It's supposed to jump to the java 9 source contents/java.base/java.io/PrintStream.class.

Actually the java language server was launched by the new java 9 jvm, but the workspace cached the old JRE 8 system libraries and user has no way to change the JRE system libraries.

Current workaround is to clean up the vscode local storage directory C:\Users\jinbwan\AppData\Roaming\Code - Insiders\User\workspaceStorage.

Expected:
When vscode-java extension startup, update the workspace jre container to the one under JAVA_HOME silently.
Or provide a command to allow user to update the workspace JRE container.

Current Workaround for Ubtuntu (cleared .config/Code/User/workspace) not working.

@fbricon

If there are JDK8 and JDK9 in the workspace, Java LS will configure a project's JRE based on the project settings.
If you want to use JDK9, you should add:

<plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.7.0</version>
    <configuration>
        <source>9</source>
        <target>9</target>
    </configuration>
</plugin>

to your pom.xml

@fbricon We can remove all JREs except a JRE defined with the java.home property.

@snjeza

as a best practice, you should prefer <release> over the <source>+<target> combo, since the compiler will check no unavailable APIs will be leaked during compilation. Only works for Java9+ projects though.

<plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.7.0</version>
    <configuration>
        <release>9</release>
    </configuration>
</plugin>

@snjeza not sure about removing other JREs. You still need to be able to switch between JDK easily, eg. 1.8 -> 9. I need to think about it.

@testforstephen

@testforstephen is this still an issue?

vscode: 1.77.1
Extension Pack for Java: v0.25.1
Language Support for Java(TM) by Red Hat: v1.16.0
Gradle for Java v3.12.7

Just encountered this issue or a similar issue. Upgraded a project from 11 to 17. Gradle Tasks vscode-gradle worked with 17, but the vscode-java tooling continued to use Java 11. All settings were ignored: https://github.com/redhat-developer/vscode-java#setting-the-jdk The workaround above worked. I deleted the workspace storage and everything was fine:

rm -rf ~/.config/Code/User/workspaceStorage

Workaround documented and continues to work, as per recent comments. Closing issue.

Prefer adding explicit project settings, but in worst case, removing the workspace storage also helps.

Navigation Menu

Repository navigation

Update jdk and old workspace still points to the stale JRE system libraries #355

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Update jdk and old workspace still points to the stale JRE system libraries #355

Description

Activity

ikbalsingh commented on Jan 20, 2018

snjeza commented on Feb 20, 2018

fbricon commented on Feb 20, 2018

fbricon commented on May 19, 2020

13rac1 commented on Apr 6, 2023

robstryker commented on Oct 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions