Debugger cannot display source for JDK/dependency classes (jdt:// frame URIs, sourceReference: 0)

The report traces the failure to the bundled Java debug adapter's StackTraceRequestHandler, JdtSourceLookUpProvider, and SourceRequestHandler; it does not identify those files in the repository. Start by locating the stack trace source construction and the existing source handle registration path. Check how jdt:// sources are represented in DAP frames, then verify that a source request can retrieve their content and that the frame receives a usable source reference.

Summary

Stepping into JDK or third-party library classes works (the frame shows up in the call stack), but no source can be displayed: the debug adapter reports every non-project frame's source as a jdt://contents/... URI with sourceReference: 0, which Zed cannot resolve. VS Code can render these URIs because the vscode-java extension registers a jdt:// content provider; Zed has no such provider and needs either an absolute file path or a non-zero DAP sourceReference to fetch source content.

Environment

Zed	1.27.0 (c84af5b99cbc366d675064e52b23664a015b6e35)
Java extension	6.8.30 (jdt.ls 1.63.0, com.microsoft.java.debug.plugin-0.53.2.jar)
OS	Windows 11 (10.0.26300) x64
JDK	Temurin 25.0.2+10 (%JAVA_HOME%\lib\src.zip present)
Project	minimal Maven project, maven.compiler.release=17, dependency commons-lang3:3.17.0

Repro

src/main/java/demo/Main.java:

package demo;

import org.apache.commons.lang3.StringUtils;

public class Main {
    public static void main(String[] args) {
        String pretty = StringUtils.capitalize("world"); // breakpoint here, then Step Into (F11)
        System.out.println(pretty);
    }
}

.zed/debug.json:

[
  {
    "label": "demo: debug main",
    "adapter": "Java",
    "request": "launch",
    "mainClass": "demo.Main",
    "cwd": "$ZED_WORKTREE_ROOT",
    "stopOnEntry": true
  }
]

Step Into on the StringUtils.capitalize line: the call stack correctly gains a StringUtils.capitalize frame, but the editor shows nothing, and Zed.log fills with:

ERROR [crates::debugger_ui/src/session/running/stack_frame_list.rs:829] no absolute source path in stack frame 6, source: Some(Source {
  name: Some("StringUtils.java"),
  path: Some("jdt://contents/commons-lang3-3.17.0.jar/org.apache.commons.lang3/StringUtils.class?=zed-java-debug-demo/C:%5C/Users%5C/...%5C/commons-lang3-3.17.0.jar=/...=%3Corg.apache.commons.lang3(StringUtils.class"),
  source_reference: Some(0), ... })

Same behavior for JDK classes (java.lang.*, etc.): the frame appears, the source cannot be shown.

Root cause analysis

Inspecting com.microsoft.java.debug.plugin-0.53.2.jar (the bundled Microsoft java-debug server):

1. JdtSourceLookUpProvider#getSourceFileURI(sourcePath, sourceName) returns a real file URI only when the lookup result is an IResource (workspace source file). Every class resolved as an IClassFile — i.e. anything from a jar or the JRT runtime, whether or not a sources jar / src.zip is attached — is turned into a jdt://contents/... URI by getFileURI(IClassFile).
2. StackTraceRequestHandler emits that URI as Types.Source.path and leaves sourceReference at 0, so a DAP client has no way to fetch the content either. (The debugSupportOnDecompiledSource == ON branch only remaps line numbers; it does not set a sourceReference.)

So on any client other than VS Code (which resolves jdt:// via a content provider querying jdt.ls), library/JDK frames are source-less.

Things that do not fix it, for the record:

• src.zip present / java.maven.downloadSources: true — the frame URI stays jdt:// even with sources attached; it only changes what content VS Code shows.
• "sourcePaths": [...] in the launch config — the plugin's source lookup never consumes it (no directory source container is created from it).
• stepFilters — not the issue here; stepping does enter the code.

Suggested fix

The adapter already has everything needed to serve this content over DAP: SourceRequestHandler implements the source request via IDebugAdapterContext#getSourceUri(int) → ISourceLookUpProvider#getSourceContents(String), and JdtSourceLookUpProvider#getSourceContents already returns source/decompiled content for jdt:// URIs.

So for frames whose resolved source is a jdt:// URI, it should additionally register the URI in sourceHandles and set source.sourceReference to that handle (optionally only when the client doesn't advertise jdt:// support). Then Zed — and any other non-VS Code DAP client — could display (and set breakpoints in, given supportsBreakpointLocationsRequest/line mapping) JDK and dependency sources.

Happy to provide logs or test a patched build on Windows.

Benchmark

For comparison, IntelliJ and VS Code (Extension Pack for Java) both display real or decompiled source for these frames.