Java-Debug is not always conforming the Debugger Adapter Protocol

Start with the protocol path through JsonUtils.java, AbstractProtocolServer.java, and ProtocolServer.java, then reproduce requests with null arguments and repeated threads requests. Check the DAP threads response and source handling for classes returned with jdt:// URIs. Done means null arguments no longer throw, threads responses include threads, and non-project classes use sourceReference with the source request.

• 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 https://github.com/microsoft/java-debug/issues/259#issuecomment-695097967).
  This requires a special workaround in https://github.com/daveleroy/sublime_debugger/pull/106.