Java-Debug is not always conforming the Debugger Adapter Protocol

[LDAP]

• Commands that have arguments set to null throw an exception:

  jdtls: 08.03.2021, 23:12:44 Error parsing message: com.google.gson.JsonSyntaxException: Expected a com.google.gson.JsonObject but was com.google.gson.JsonNull
  Expected a com.google.gson.JsonObject but was com.google.gson.JsonNull
  com.google.gson.JsonSyntaxException: Expected a com.google.gson.JsonObject but was com.google.gson.JsonNull
      at com.google.gson.internal.bind.TypeAdapters$35$1.read(TypeAdapters.java:897)
      at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:131)
      at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:222)
      at com.google.gson.Gson.fromJson(Gson.java:932)
      at com.google.gson.Gson.fromJson(Gson.java:897)
      at com.google.gson.Gson.fromJson(Gson.java:846)
      at com.google.gson.Gson.fromJson(Gson.java:817)
      at com.microsoft.java.debug.core.protocol.JsonUtils.fromJson(JsonUtils.java:26)
      at com.microsoft.java.debug.core.protocol.AbstractProtocolServer.processData(AbstractProtocolServer.java:219)
      at com.microsoft.java.debug.core.protocol.AbstractProtocolServer.run(AbstractProtocolServer.java:98)
      at com.microsoft.java.debug.core.adapter.ProtocolServer.run(ProtocolServer.java:61)
      at com.microsoft.java.debug.plugin.internal.JavaDebugServer$2.run(JavaDebugServer.java:136)
      at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
      at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
      at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
      at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
      at java.base/java.lang.Thread.run(Thread.java:832)
  

  However, commands that do not need arguments, e.g. (configurationDone, threads) should be able to set arguments to null as the Thread Request does not set any restrictions. See here.

• The response to threads request does not always contain the threads key.
  Protocol:

  ⟸ request/threads(8) :: {}
  ⟸ request/threads(9) :: {}
  ⟸ request/threads(10) :: {}
  ⟸ request/threads(11) :: {}
  ⟸ request/threads(12) :: {}
  ⟸ request/threads(13) :: {}
  ⟹ response/threads(8) :: None
  ⟹ response/threads(9) :: None
  ⟹ response/threads(10) :: None
  ⟹ response/threads(11) :: None
  ⟹ response/threads(12) :: None
  ⟹ response/threads(13) :: None
  

  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 the java/classFileContents LSP request. Java-Debug should instead set the sourceReference value > 0 and the contents of the source must be retrieved through the source request (See Could not load source '': SourceRequest: property 'sourceReference' is missing, null, or empty. #259 (comment)).
  This requires a special workaround in Java adapter daveleroy/SublimeDebugger#106.

[mickaelistria]

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?

[testforstephen]

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:

• This Java debug project was set up earlier than LSP4E.debug and lsp4j.debug.
• This Java-debug project uses JDI directly. However, LSP4E.debug is built on top of Eclipse Platform Debug framework, that doesn't meet our needs.

[mickaelistria]

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 ?

[testforstephen]

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.