Open LDAP opened 2 years ago
I'm curious about this issue. What is the reason why not using the LSP4E.debug support for the Debug Adapter Protocol? Wouldn't using it provide more guarantee of conformance? Are there some known drawbacks?
I'm curious about this issue. What is the reason why not using the LSP4E.debug support for the Debug Adapter Protocol? Wouldn't using it provide more guarantee of conformance? Are there some known drawbacks?
There are two reasons:
Sorry, I made a typo in my previous comment. I was only thinking of LSP4J.debug part; the client side (LSP4E.debug and Eclipse Platform Debug) is totally out of the scope here. So let's focus on
This Java debug project was set up earlier than LSP4E.debug and lsp4j.debug.
Do you think it would make sense to switch it to lsp4j.debug ?
The original issue actually has three different use case. The first one involves JSON de-serialization and it might help by switching to lsp4j.debug. However, the other two use cases are related to the DAP implementation and lsp4j.debug won't help for them. I don't see much business benefit to switch it to lsp4j.debug.
Commands that have
arguments
set tonull
throw an exception:However, commands that do not need arguments, e.g. (
configurationDone
,threads
) should be able to set arguments tonull
as the Thread Request does not set any restrictions. See here.The response to
threads
request does not always contain thethreads
key. Protocol:See here.
When stepping into classes that are not represented by a project file, Java-Debug returns a path with URI scheme
jdt://
which then can be used to retrieve the class content using thejava/classFileContents
LSP request. Java-Debug should instead set the sourceReference value > 0 and the contents of the source must be retrieved through thesource
request (See https://github.com/microsoft/java-debug/issues/259#issuecomment-695097967). This requires a special workaround in https://github.com/daveleroy/sublime_debugger/pull/106.