I'm creating this issue to track my own findings while investigating using the language server with the extension. I once I have completed the objectives set out in this task, I will report back to the parent issue with general findings.
Objectives
Start the language server binaries as a sub-process
Ensure that we can read/write to the appropriate stdio streams
Setup basic JSON-RPC to demonstrate bidirectional RPC support
If you do not feel the purpose of this issue matches one of the types, you may apply the typeignore label to exclude it from type tracking metrics and future prompts.
I've spent the past couple of days working on setting up my environment to contribute to the jetbrains extension and starting the process of integrating the language server in a quick POC sort of way. So far, I have been able to start a new process. Read/Write to the stdio of the new process. Redirect the stderr stream to stdout (since we are using stderr in the LS and don't want to shutdown the process). I am currently working to incorporate a bidirectional JSON-RPC client. But there are not a lot of good java/kotlin libraries for working with JSON-RPC (especially via stdio as the transport layer).
This has gotten me pretty far, but bidirectionality is not supported. There might be a way to run both a server and client in the extension (but we'd need to read from the same io streams). However, I haven't gotten this working yet. I need to try creating an "observable" input stream such that it saves all bytes until all subscribers have read it (?).
If this doesn't work, we might get more traction in the POC to just write a JSON-RPC implementation ourselves.
NOTE: I am currently embedding the binaries directly in the .jar for simplicity. But this is not a requirement and would most likely change for a real implementation.
I've abandoned jsonrpc4j and instead am working with lsp4j. This is working splendidly. I now have the LS running in a subprocess and handling JSON-RPC over stdio. I've implemented the initialize rpc call and was able to both send requests and receive responses. I have updated the branch with the latest code.
Next I plan on implementing a few more RPC calls that we can make to the language server so we can test a few different scenarios. I'll also set up a meeting with @dbernardi early next week to go over findings and my current approach.
Today, @erran brought up a good point in Slack today regarding the license for the lsp4j library. To ensure that we are making a well-informed decision, is there any way to confirm that this license will work for our use case from an organizational perspective?
If we cannot use this dependency, we might have to consider writing our own JSON-RPC layer. For this effort, I'm not really delving into what libraries we'd want to use. My focus at the moment is on validating whether we can successfully launch the language server as a subprocess and facilitate JSON-RPC communication through stdio streams. So far the results for this have been very positive.
is there any way to confirm that this license will work for our use case from an organizational perspective?
@john-slaughter I'm not sure how we usually check for this. Before I go down the rabbit hole, @phikai I feel like you might know the answer to this one?