Skip to content

Troubleshooting

Jump to bottom
issuelens[bot] edited this page Oct 30, 2026 · 3 revisions

Troubleshooting

Gradle BSP importer: malformed or unmapped model data

This section concerns the JDTLS Gradle Build Server importer adapter in microsoft/vscode-gradle, not the task service or the separate Gradle Build Server implementation. Evidence is pinned to merged/source-tip commit 608fdad0e7a22bbcd70c05edc396783ca97b6c9f, PR #1931. Source identity: microsoft/vscode-gradle#1931:608fdad0e7a22bbcd70c05edc396783ca97b6c9f.

At this revision, GradleBuildServerBuildSupport handles four invalid-data boundaries without dereferencing a missing value:

  • getProjectDependencyEntries logs the dependency URI and importing project, then skips a BSP project dependency when its URI does not resolve to an Eclipse workspace project. Diagnose the BSP-to-workspace mapping rather than treating the missing classpath entry as a task-service failure.
  • getOutputFullPath logs and returns no path when an output URI cannot be converted to a filesystem path, including non-file URIs. Its callers already treat a missing source output as an error and a missing resource output as nullable, so no output folder is created from an invalid path.
  • getJvmTarget logs the build-target identifier and skips a JVM target whose decoded JvmBuildTargetEx metadata is missing or invalid. Other valid JVM targets can still contribute Java home, Gradle version, and source/target compatibility; if none provide required values, the existing warning about empty Java home or Gradle version still applies.
  • getDependencyJars logs Maven coordinates and skips a Maven dependency whose decoded MavenDependencyModule metadata is missing or invalid. This prevents that malformed entry from contributing a classpath library while allowing remaining dependency modules to be processed.

Use the emitted identifiers to distinguish malformed BSP metadata, a non-file output URI, or an unmapped workspace project from unrelated Gradle task discovery and transport failures. These guards preserve processing where possible; they do not repair the originating model data or guarantee that an import with missing required inputs is complete.

The complete PR changed only the linked implementation file (23 additions, 2 deletions). Its one-file patch and final file were inspected, PR metadata was rechecked after paging, and the final source was verified at the full commit SHA above. No tests changed in the PR, and this maintenance review did not execute tests, reproduce failures, or establish release/deployment.

Windows process discovery is restricted by PowerShell policy

At source revision a114556f000e60fa2bf48924829d0b1118f0eac5 (microsoft/vscode-java-debug PR #1722), getProcesses uses Windows PowerShell and CIM instead of WMIC. If PowerShell is in Constrained Language mode while its output code page is not UTF-8, the script refuses process discovery because it cannot safely change the encoding; its guidance is to attach using hostName and port instead. Check the PowerShell language mode and output encoding when Windows process enumeration fails, and distinguish that restriction from a missing JVM or a debug-server DAP failure.

CIM errors are terminating, while the higher-level getProcessTree catches enumeration failures and returns undefined; therefore the exact PowerShell text is not guaranteed to appear in every UI path. The linked source and test/processTree.test.ts establish implementation and asserted cases, not test execution or a reproduced user environment. See Java Debugger Extension: Windows process discovery. Source identity: microsoft/vscode-java-debug#1722:a114556f000e60fa2bf48924829d0b1118f0eac5.

Java breakpoints remain unverified for encoded source

For source commit a658059daa820c9d532407eba3c1ae7697d4ef2b (microsoft/java-debug PR #647), breakpoint class-name/location resolution honors Eclipse workspace file/project encodings and recognizes UTF-8, UTF-16LE, and UTF-16BE BOMs on external files. External files without a recognized BOM still use the language-server JVM's default charset. If resolution still fails, identify whether the file is a workspace resource or external file, verify its configured encoding or BOM, and inspect server logs for Failed to read source file: <path>. See Java Debug Server: Breakpoint resolution for encoded source files for implementation boundaries, immutable source links, test coverage, and provenance.

Clone this wiki locally