Java-Debug is not always conforming the Debugger Adapter Protocol

Comece pelo caminho do protocolo através de JsonUtils.java, AbstractProtocolServer.java e ProtocolServer.java e, em seguida, reproduza solicitações com argumentos null e solicitações threads repetidas. Verifique a resposta DAP de threads e o tratamento de source para classes retornadas com URIs jdt://. Está concluído quando os argumentos null não causarem mais exceções, as respostas de threads incluírem threads e as classes que não pertencem ao projeto usarem sourceReference com a solicitação source.

• 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.