GH2577: Add '-Xlog:jni+resolve=off' to the default vmargs #2646
Conversation
Signed-off-by: Jinbo Wang <[email protected]>
|
I think you should also add it dynamically if necessary (like we do for logging or jpms modules), in case user already uses custom VM args. |
Signed-off-by: Jinbo Wang <[email protected]>
done. |
There was a problem hiding this comment.
Looks fine to me. I did some quick research and noticed there's -Xlog:disable also. If the language server is communicating via std streams, there's probably a good argument to make for disabling logging completelyin the JVM when the client/server are using the standard streams, but maybe we can investigate that after.
It would be interesting to know if there's older issues with similar failure.
…eloper#2646) * Add '-Xlog:jni+resolve' to vmargs dynamically Signed-off-by: Jinbo Wang <[email protected]>
…eloper#2646) * Add '-Xlog:jni+resolve' to vmargs dynamically Signed-off-by: Jinbo Wang <[email protected]>
Just wanted to note that this fixed the issue for me (Windows 10, VS Code 1.72.2, Java 17) when the other version didn’t. |
This should be the default now. After discovering other issues that seemed very related to this, I thought there might be other JVM components that use the logging facility, so best to disable it entirely ( #2690 ) |
Signed-off-by: Jinbo Wang [email protected]
Mitigate the issue #2577 (comment). The parameter
-Xlog:jni+resolve=offis used to prevent some unexpected jni logs from being logged to stdout, because Java language server uses stdio as the jsonrpc channel by default.