Java-Debug is not always conforming the Debugger Adapter Protocol

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.

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:

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.

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.

Lucas Alber (@LDAP)

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!

Navigation Menu

Repository navigation

Java-Debug is not always conforming the Debugger Adapter Protocol #444

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Java-Debug is not always conforming the Debugger Adapter Protocol #444

Description

Activity

mickaelistria commented on Mar 31, 2023

testforstephen commented on Apr 3, 2023

mickaelistria commented on Apr 3, 2023

testforstephen commented on Apr 4, 2023

github-actions commented on Nov 14, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions