Debugger: DAP types incompatible with some dap servers

[DeityLamb]

Summary

DAP types incompatible with some DAP servers

Description

Some DAP Servers (Hello Java again) put -1 into line in StackFrame when source is missing, instead of 0, while Zed expects line to be u64. This breaks frame capturing.
https://github.com/zed-industries/dap-types/blob/master/dap-types/src/types.rs#L2215

1. Open Spring Boot project
2. Start debugging
3. Add break points to route
4. Make some requests

Expected Behavior:
Debugging works in all cases
Actual Behavior:
It breaks when frame line is -1

I tried mapping line to 0 if it’s -1 for testing, and it worked.
DeityLamb/dap-types@d8419e3

Video

2025-08-28_12-37-27.mp4

Related issues zed-extensions/java#74

Zed Version and System Specs

Zed: v0.200.5 (Zed)
OS: Linux Wayland void unknown
Memory: 14.9 GiB
Architecture: x86_64
GPU: AMD Radeon Graphics (RADV REMBRANDT) || radv || Mesa 25.1.3

[osiewicz]

That's a violation on Java's DAP. Spec clearly states:

  /**
   * The line within the source of the frame. If the source attribute is missing
   * or doesn't exist, `line` is 0 and should be ignored by the client.
   */
  line: number;

I don't think we should change anything about our implementation of a DAP client.

[DeityLamb]

@osiewicz

I agree that this is more likely an issue in java-debug, but
it also doesn’t say here that line cannot be negative,
so they aren’t breaking the protocol either.

I quickly checked the code and it seems changing the type to i64 should be enough to make it work.
I could make a PR for this if you’re okay with the solution

[DeityLamb]

To be honest, the last release of java-debug was in 2024
Even if we open an issue for them, it's unclear when a new release with an update would appear
That's assuming they even agree the problem is on their end

It would be great to implement full Java debugger support in zed now, rather than within the next 1-2 business years 🐈

[osiewicz]

This is why I've opened an issue against the spec a while ago: microsoft/debug-adapter-protocol#551
It also goes into a bit of detail as to why just using i64 is not a sufficient solution.
Overall I'm quite reluctant about adjusting ourselves to muddy interpretations of the spec like that; if java-debug is not maintained, then we'll have to bend ourselves backwards to fix any discrepancy in our/theirs interpretation of the spec. We've had good luck talking to maintainers of GDB and Delve and figuring out a middle-ground when it came to spec interpretation; if we can't do that with java-debug, I think the best way forward would be to fork it.

[DeityLamb]

By the way, It seems the specification states all integers may be 32-bit signed, but it uses the word 'may' 🤷‍♂️
https://microsoft.github.io/debug-adapter-protocol/overview#:~:text=type%20integer)-,may%20be%20represented%20as%2032%20bit%20signed,-%20integers

microsoft/debug-adapter-protocol#422 (comment)

Anyway, thank you for moving the standards toward a single format. It's much more work than just choosing the broadest interpretation, but someone still has to do it, and I really appreciate your effort with that 🐱

[Anthony-Eid]

The protocol seems to specify whether a field can be negative in comments. If you search for "negative" on this page https://microsoft.github.io/debug-adapter-protocol/specification you'll find 8 matches. 7 describes that fields named offset can be negative and one describes that instructionOffset can be negative.

I do agree that the protocol should be more clear on this though

[playdohface]

Can we expect any movement on this issue? My reading of the spec is that u64 is not actually the spec-compliant integer type. The (admittedly unfortunate) verbatim of the spec is:

integers defined in the protocol (JSON schema type integer) may be represented as 32 bit signed integers, although some properties disallow negative values.

Clearly java-debug is still the one at fault here, as the correct value in this particular instance should clearly be 0 and not -1.
However if the concern is that using i64 would be less correct than u64 and that is the reason why debug support for java will have to remain indefinitely broken, I really don't see the reasoning. The need to support line numbers larger than i64::MAX or u64::MAX as a special value of some kind seem a bit silly to me.

[playdohface]

FWIW I fixed the issue on the java-debug side, let's see if the maintainers agree: microsoft/java-debug#609

This also uncovered another issue for me: java-debug will just set the source field to null in its current version and Zed does not handle this gracefully. The fix from the java-debug side is simple, but in this case it's less clear who is at fault and I'd argue it is Zed as the source field is clearly optional in the spec, which should just yield None in Rust regardless of whether it ends up being undefined or null on the wire.

[Anthony-Eid]

@playdohface what do you mean by Zed handles source being none ungracefully? I would love more context to understand and fix that issue