Implement Workspace Diagnostic Scanning (Issue 31)

[Moataz-Aldawood]

Pull Request: Implement Workspace Diagnostic Scanning (Issue #31)

Overview

This PR introduces a much-requested feature: the ability to proactively scan an entire workspace for compilation errors and warnings without requiring the user to open every file manually. It fulfills Issue #31 and also addresses exclusion glob-patterns requested in Issue #19.

---

Changes & Features Introduced

1. Workspace Scanning Configuration:

   • netbeans.autoScanWorkspace: A new boolean setting (default: false) that allows users to automatically trigger a full workspace diagnostic scan whenever they load a project.
   • netbeans.scanExclude: A new array configuration (default: ["**/node_modules/**", "**/target/**", "**/build/**"]) allowing users to define glob patterns for directories that should be skipped during the scan to save resources.

2. New User Commands:

   • nbls.workspace.scan (Java: Scan Workspace for Diagnostics): Allows the user to manually trigger a background scan of all .java files in the workspace at any time. It includes a cancellable VS Code progress bar.
   • nbls.workspace.scan.clear (Java: Clear Workspace Diagnostics): A utility command to instantly clear all background scan results from the custom VS Code Problems panel collection.

3. Background Scanner Logic (extension.ts):

   • Implemented doWorkspaceScan which batch processes files by invoking the backend nbls.get.diagnostics command in small chunks. This prevents overloading the LSP server with hundreds of simultaneous parsing requests.
   • Added specific client-side filtering to gracefully drop massive ExceptionInInitializerError stack traces caused by upstream Lombok incompatibilities.

---

Fixes

Critical Bug Fix in TextDocumentServiceImpl.java
While implementing the scanner, we discovered a major bug in the computeDiagnostics method inside the backend language server. Previously, when the server computed errors and hints simultaneously, the resulting result list was being overwritten rather than aggregated. This caused standard compilation errors to randomly disappear or be completely overwritten by simple code hints.

• Fix: Refactored computeDiagnostics to use an ArrayList<> and .addAll() so that both ERRORS and HINTS are correctly merged and returned to the client in a single payload.

---

Challenges Encountered

Lombok Compatibility on master Branch:
During testing on the master branch, we encountered a significant challenge with Lombok throwing fatal java.lang.NoClassDefFoundError: Could not initialize class lombok.javac.Javac exceptions.

• Investigation: We discovered this is an upstream regression in the apache/netbeans master branch. The NetBeans team recently updated the internal nbjavac compiler to Java 22/23 and unfortunately dropped the EndPosTable compatibility patch (which existed in NetBeans 21) that allowed Lombok to function on newer JDKs.
• Resolution: Because this is an upstream compiler issue, we cannot fix it inside the VS Code extension wrapper. We implemented a temporary client-side filter in the scanner to prevent these massive, noisy stack traces from flooding the user's Problems panel, whilst continuing to report the valid Java cannot find symbol errors that result from the failed Lombok processing.

Native LSP Diagnostic Caching:
We encountered confusion regarding lingering diagnostics in the Problems panel after closing files. This is due to the native vscode-languageclient architecture where the backend server does not explicitly send empty arrays ([]) to clear diagnostics when files are closed. We solved this from the user's perspective by keeping our background scan results isolated in a separate, clearable custom bucket (projectDiagnosticCollection).

---

Recommendations for Upstream

1. Restore EndPosTable in nbjavac: We highly recommend filing a bug against the core apache/netbeans repository to reinstate the dummy EndPosTable patch in nbjavac for Java 22/23. Until this is fixed upstream, Lombok users running the latest NetBeans Language Server on modern JDKs will experience completely broken annotation processing.
2. Empty Diagnostic Arrays on didClose: The NetBeans Language Server should be updated to actively send publishDiagnostics(uri, []) when it receives a didClose notification for a file, ensuring that the VS Code Problems panel cleans up gracefully when a user closes a broken file.

---

PR approval and merge checklist:

1. Is this PR squashed?
2. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
3. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?