You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Keep the project JDK shown in Project Settings in sync with the runtime inventory, without cleaning the Java workspace or restarting VS Code.
Refresh VM installations after resolving project classpath settings, and publish the runtime list with the selected project JDK in one message/state update.
Ignore superseded inventory replies and classpath replies for a project that is no longer selected. Preserve the existing filesystem-based project matching on Windows.
Publish successful empty inventories instead of retaining stale choices. Report inventory failures through telemetry and a notification while retaining the actual project JDK information.
Show an explicit disabled current-JDK/unknown-JDK option when the selected path has no matching runtime, rather than allowing the select component to display the first installed JDK. Add a Refresh JDKs action; inventory-only refreshes preserve unapplied JDK choices.
Extend the existing classpath AutoTest plan to cover current-JDK selection and refresh, while retaining its Add Library/apply regression.
This changes project-JDK presentation and synchronization only. It does not select or upgrade the language-server/tooling JDK and is independent of #1765/#1768.
Evidence and draft scope
The original screenshot shows JavaSE-24 and JDK 24 library paths in Java Projects, while Project Settings displays a JDK 21 runtime.
In the reported 0.29.2 implementation, project settings and the VM list were loaded independently. Classpath update events refreshed the selected path but did not refresh the runtime choices. The same data-flow gap was still present on main.
The focused regressions demonstrate the late-registration/stale-inventory case, out-of-order replies, empty/failed inventory handling, and unavailable selection rendering. Eight of the ten cases failed before this fix.
The original user's API responses and workspace cache are unavailable, so this draft does not claim the exact original cache failure has been reproduced. Reporter confirmation is still needed; the local UI run verifies current-JDK availability across refresh, not an injected JDK 21-to-24 startup race.
Validation
npm test -- --test-reporter=dot: 78 passed, including 10 focused project-settings cases.
Production extension/webview build and branch VSIX packaging succeeded.
Final packaged branch VSIX: java-extension-pack.yaml on Windows, stable VS Code, --no-llm: 15/15 passed. Inspected the result report and JDK-tab screenshots.
git diff --check: clean.
Local packaging used a temporary ignore file to exclude an untracked .env; no environment file or local validation artifact is included in this PR.
Refresh runtime choices with project classpath settings and keep unavailable selections explicit. Add focused regressions and extend the existing classpath AutoTest plan for issue #1443.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9bfdb23d-9b06-41ae-8d99-0ab1fb561743
Tested the packaged PR base (dc8ddca) and head (3c8e758) with the same scenario on Windows, VS Code 1.141.0, and redhat.java1.56.0.
Project Settings stays open at JDK 21. An AutoTest-only helper then calls the upstream java.project.updateJdk command to switch the project to a newly registered JDK 24 path. jdk-24-1443 is a directory junction to a real JDK 24 installation, verified by javac -version returning javac 24. No UI state or Java-server replies are mocked; no restart, cache reset, or manual Refresh JDKs occurs during the switch.
Before: Java Projects and the actual project path already point to JDK 24, but the dropdown displays 21.0.12.1-win32-x86_64.
After: the dropdown automatically selects jdk-24-1443, matching the project tree and actual runtime.
Deterministic evidence:java.project.getSettings confirms the project runtime path; java.vm.getAllInstalls confirms the new path is absent initially and registered after the switch. The final AutoTest head run passes 14/14, including a selector targeting the displayed combobox label (not just a matching option in the list). The identical base run passes 13/14; the JDK 24 selected-label selector is absent, recorded as an error by AutoTest.
Images are cropped, highlighted, and have only the local path prefix redacted; displayed JDK values are unchanged. This verifies the newly registered project-JDK synchronization failure addressed by this PR and reproduces #1443's visible 24-versus-21 mismatch. It does not establish the exact cache history of the original reporter's workspace.
Check the inventory request ID before reporting errors so a stale failed request cannot emit telemetry or notify users after a newer request succeeds. Add a regression test while preserving error reporting for the current request.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: a7196b98-8fa1-4856-a96b-663c8c3cd0c9
On Windows, this strict string comparison treats the same JDK installation as missing when drive-letter/path casing differs (for example, C:\Java\jdk-24 versus c:\JAVA\JDK-24). That makes the new disabled “not listed” option appear for a valid runtime and leaves the select value unmatched. Compare paths using Windows filesystem semantics and use the matched inventory entry’s canonical path for both selected and the select element value.
Verify refresh completion and exact selected JDK change
test-plans/java-extension-pack.yaml:94
The refresh check can pass before the inventory response arrives because every verifyWebview condition here is already true before clicking Refresh JDKs; the next locator likewise accepts any enabled selected option. A no-op refresh or a response that switches to another installed JDK therefore still passes. Add a deterministic completion signal and compare the exact selected option value before and after refresh (or use a controlled fixture that makes the refreshed inventory observably different).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Refs #1443.
Keep the project JDK shown in Project Settings in sync with the runtime inventory, without cleaning the Java workspace or restarting VS Code.
This changes project-JDK presentation and synchronization only. It does not select or upgrade the language-server/tooling JDK and is independent of #1765/#1768.
Evidence and draft scope
The original screenshot shows
JavaSE-24and JDK 24 library paths in Java Projects, while Project Settings displays a JDK 21 runtime.In the reported 0.29.2 implementation, project settings and the VM list were loaded independently. Classpath update events refreshed the selected path but did not refresh the runtime choices. The same data-flow gap was still present on
main.The focused regressions demonstrate the late-registration/stale-inventory case, out-of-order replies, empty/failed inventory handling, and unavailable selection rendering. Eight of the ten cases failed before this fix.
The original user's API responses and workspace cache are unavailable, so this draft does not claim the exact original cache failure has been reproduced. Reporter confirmation is still needed; the local UI run verifies current-JDK availability across refresh, not an injected JDK 21-to-24 startup race.
Validation
npm test -- --test-reporter=dot: 78 passed, including 10 focused project-settings cases.npx -y @vscjava/vscode-autotest validate test-plans\java-extension-pack.yaml: valid.java-extension-pack.yamlon Windows, stable VS Code,--no-llm: 15/15 passed. Inspected the result report and JDK-tab screenshots.git diff --check: clean.Local packaging used a temporary ignore file to exclude an untracked
.env; no environment file or local validation artifact is included in this PR.