Closed sebthom closed 2 years ago
Same issue when using latest LSP4J 0.16.0:
Oct 17, 2022 11:40:30 PM org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer fireError
SEVERE: Failed making constructor 'java.lang.Void#Void()' accessible; either change its visibility or write a custom InstanceCreator or TypeAdapter for its declaring type: Unable to make private java.lang.Void() accessible: module java.base does not "opens java.lang" to unnamed module @159040aa
com.google.gson.JsonIOException: Failed making constructor 'java.lang.Void#Void()' accessible; either change its visibility or write a custom InstanceCreator or TypeAdapter for its declaring type: Unable to make private java.lang.Void() accessible: module java.base does not "opens java.lang" to unnamed module @159040aa
at com.google.gson.internal.ConstructorConstructor$8.construct(ConstructorConstructor.java:233)
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:256)
at com.google.gson.Gson.fromJson(Gson.java:1058)
at com.google.gson.Gson.fromJson(Gson.java:1129)
at org.eclipse.lsp4j.jsonrpc.debug.adapters.DebugMessageTypeAdapter.createMessage(DebugMessageTypeAdapter.java:392)
at org.eclipse.lsp4j.jsonrpc.debug.adapters.DebugMessageTypeAdapter.read(DebugMessageTypeAdapter.java:255)
at org.eclipse.lsp4j.jsonrpc.debug.adapters.DebugMessageTypeAdapter.read(DebugMessageTypeAdapter.java:157)
at com.google.gson.Gson.fromJson(Gson.java:1058)
at org.eclipse.lsp4j.jsonrpc.json.MessageJsonHandler.parseMessage(MessageJsonHandler.java:119)
at org.eclipse.lsp4j.jsonrpc.json.MessageJsonHandler.parseMessage(MessageJsonHandler.java:114)
at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:193)
at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:94)
at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:113)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
@sebthom the issue here is the debug adapter is returning a non-void response body to configurationDone
request.
LSP4J's implementation expects (and requires) that the debug adapter return void:
but in the case of the debug adapter you are working on it is returning:
{"allThreadsContinued":false}
which goes against what is documented in the DAP specification
I assume it works in VSCode. In VSCode the type system is more lenient. VSCode doesn't use the return value from configurationDone, but because the return value deserializes properly, it also doesn't complain.
It may be able to avoid the error and simply ignore the body. I have an idea for a PR, I will try that out and gather some feedback.
response
so that it is filled with the extra return stuff which is really the response of a continue
stopOnEntry
as true
to avoid the above.Ahh! A piece of the puzzle I missed before. Java 17! Which leaves you option 3 in what can you do:
--add-opens java.base/java.lang=ALL-UNNAMED
@jonahgraham thanks a lot for looking into this. that helps a lot.
Regarding the spec, it doesn't seem to be really clear. Response to configurationDone request. This is just an acknowledgement, so no body field is required.
does not say that a response body is prohibited only that it is not required.
Ahh! A piece of the puzzle I missed before. Java 17! Which leaves you option 3 in what can you do:
3. Until this issue is fixed, run with `--add-opens java.base/java.lang=ALL-UNNAMED`
Using this for now. Works. Thanks!
Regarding the spec, it doesn't seem to be really clear.
Response to configurationDone request. This is just an acknowledgement, so no body field is required.
does not say that a response body is prohibited only that it is not required.
Yes, I think you are correct. The LSP4J implementation is overly restrictive in this regard.
Regarding the spec, it doesn't seem to be really clear.
Response to configurationDone request. This is just an acknowledgement, so no body field is required.
does not say that a response body is prohibited only that it is not required.Yes, I think you are correct. The LSP4J implementation is overly restrictive in this regard.
@sebthom FYI #721 was recently raised on this topic.
I am trying to get launching debug sessions working with the haxe-language-server and it's debug adapter eval-debugger using LSP4J 0.15.0 and LSP4E 0.20.7.
However when I launch the session, LSP4J and the debugger process are communicating until the progress hangs at this step:
The following exception is visible in the log: com.google.gson.JsonIOException: Failed making constructor 'java.lang.Void#Void()' accessible
Here is a screenshot of the stacktrace + code + variables.
This are the messages send from the debugger process:
The launch code can be found here: https://github.com/haxe4e/haxe4e/blob/0ec9dcfa2ff8fe32ef92d6a810ff497355441eec/haxe4e-plugin/src/main/java/org/haxe4e/launch/LaunchConfigLauncher.java#L133-L137
Any suggestions are highly appreciated.