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.

[github-actions]

Hi Lucas Alber (@LDAP), I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

• For handling null arguments:

  • Update the Request class to use a JsonElement (or JsonObject) for the arguments field so that JsonNull is accepted. See issue #744:
    • Request.arguments should be a JsonElement type to allow JsonNull
    • URL: The filed named arguments of Request class shoulb be JsonElement type . vscode-java-debug#744

• For the threads response missing the threads key:

  • Ensure the debug adapter always returns an object with a threads array (even if empty) per the DAP spec:
    • Spec: “The response to the threads request has the threads attribute”
    • URL: https://microsoft.github.io/debug-adapter-protocol/specification#Requests_Threads

• For non–project-file classes (jdt:// URIs):

  • Instead of using jdt://, set sourceReference > 0 and serve source via the source request. See discussion in issue Could not load source '': SourceRequest: property 'sourceReference' is missing, null, or empty. #259:
    • Comment: workaround for sourceReference
    • URL: Could not load source '': SourceRequest: property 'sourceReference' is missing, null, or empty. #259 (comment)

labels:

• bug

duplicateUrls: []

The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!