feature request: add debugger support

[npv12]

Now that zed has officially introduced support for debugger, would it be possible to add the debugger support for java as well?

I'm open to working on it but would need some guidance to get started

[valentinegb]

Sorry for the late response! I was away from my home for a week ^^'

Looks pretty possible to me! Here is Zed's debugger documentation and here's Debugger for Java, though I'm not sure if that's meant to work outside of VSCode or not.

[lirionex]

This seems to be the repo for the actual debug server: https://github.com/microsoft/java-debug

[DeityLamb]

I got a bit interested in the integration and did some quick research.

1. First of all, it seems like java-debug doesn’t provide prebuilt binaries in releases or anywhere else.
One option is to add java-debug as a submodule and build the package directly on the user's machine.
https://search.maven.org/artifact/com.microsoft.java/com.microsoft.java.debug.plugin/0.53.1/eclipse-plugin

2. java-debug works as a jdt.ls plugin rather than a standalone DAP server.
   To start the debug server, you need to send an LSP command

{
  "command": "vscode.java.startDebugSession"
}

which returns the required port.
Currently, this isn't possible with zed_extension_api zed-industries/zed#13756

One workaround is to write a wrapper (e.g., in Node.js) to launch the DAP server.
I haven’t explored this in detail yet, but there seem to be two possible approaches

• Launch another jdt.ls instance with the debugger via the wrapper.
  This is the simplest option but would mean having two running jdt.ls instances.
• Move the entire jdt.ls LSP server launch into the wrapper along with the debug plugin.
  In this case, we’d have to manage the server’s state and proxy the requests.

Hey, @valentinegb Any ideas or preferences?

[npv12]

@DeityLamb for downloading java-debug it might be possible to download it using mvn maybe? Not sure if it is ideal though

I noticed the package com.microsoft.java.debug.plugin-0.53.1.jar in maven

[DeityLamb]

@DeityLamb for downloading java-debug it might be possible to download it using mvn maybe? Not sure if it is ideal though

I noticed the package com.microsoft.java.debug.plugin-0.53.1.jar in maven

Yep, it simplifies some things
Now we just need to figure out how to run the DAP server.

[gayanper]

What if we could wrap the JDTLS using a wrapper which makes sure only once instance is running for a given workspace directory. The subsequent runs with same workspace path can forward those messages to the first instance.

This might be able to implement using local file channel to avoid using the network layer, the same file could be treated as a lock file as well.

[gayanper]

I read a bit more on the extension API,

Given the DebugAdapterBinary has both connection and command which are Optional. We could just return the connection information after running the workspace command on java LSP which will return us the port where the debug server is running.

This logic can be implemented in the get_dap_binary implementation. WDYT ?

[DeityLamb]

@gayanper The Zed extension API is pretty limited right now
We can’t just send the LSP command, so I think the wrapper is still the only option

[gayanper]

@gayanper The Zed extension API is pretty limited right now
We can’t just send the LSP command, so I think the wrapper is still the only option

Yes i found the same while looking into Zed last weekend. I wonder if we can avoid the project import part of the second LS we start if we point to same data dir. but again it could also cause a lock file issue since eclipse workspaces has locks

[DeityLamb]

Okay, I'll briefly summarize what I understood and the options we have for developing this feature

• We create a JS wrapper to proxy LSP requests
  
  Adding a file directly will be impossible
  But, we can publish the wrapper as an npm package or embed the code as a string in the build and run it via node -e
  
  Download npm package via extension
  Get node binary via extension
  
  This can be implemented now and, in theory, even expand the scope for implementing other functionality that was previously limited
  Also, we won’t have to run 2 jdtls servers because either way, we need to manage it through the wrapper
  
  But it requires moving most of the existing interaction logic with jdtls into this wrapper
  Also, a custom script like this goes beyond WebAssembly and its acceptability is unclear

• Or we can wait until zed_extension_api adds support for the required functionality

Maybe someone else has alternative options?

[DeityLamb]

Hey, @valentinegb
I could start implementing this feature using a proxy wrapper if you’re okay with all its pros and cons

[valentinegb]

@DeityLamb If you're willing to work on it then by no means will I stop you ^^
Though I don't really plan on contributing much myself at this time, as long as you can get a working solution I'll do my best to review it and get it merged :)

[gayanper]

I can help review as well from jdtls and dap point of view since i was a contributing to both jdtls and java dap my self