Better collaboration with vscode-java

[CsCherrYY]

Currently vscode-gradle starts a different daemon from vscode-java, we can find a way to reuse it, such as send our requests to language server, etc.

[badsyntax]

When I last looked at this I couldn't understand it, as buildship and this extension are both using the Gradle Tooling API, so it should be using the same daemon. It's definitely a good idea to reach out to vscode-java to try understand why different daemons are spawned.

[CsCherrYY]

I have done some investigation, and here are some thoughts and findings:

The target of this work is to reduce the daemon number of VS Code users. Now vscode-java will launch a daemon via buildship, and vscode-gradle will launch a daemon via TAPI directly, it will bring a waste of memory and resource.

eclipse.jdt.ls (language server of vscode-java) uses buildship to import and manage Gradle projects, there is a long running instance GradleCore, where we can use GradleCore.getWorkspace().getBuild(IProject) to get the GradleBuild after importing (called synchronizing in buildship) process is finished.

GradleBuild provides some ways to help us to contact with tooling API, includes

• Getting project configuration (the way we now get tasks information)
• Adding an init-script (the way we now get dependency, extension and classpath information), and so on.

IMO it's doable for us to make our server an extension of eclipse.jdt.ls, get it's running GradleCore of buildship and our extension will only get the GradleBuild via that instance. As mentioned above, that instance can do everything we need about the TAPI.

Some concerns:

• Depending on buildship might delay the time our features become available. Currently our extension only requires finishing configuration we can get the enough information, but after applying buildship's instance, we might wait for the synchronizing process.
• It might add difficulty to our work on merging the current two servers, see #1123. The gradle-language-server should work regardless of the status of project importing, although some features depend the information of TAPI model.

[CsCherrYY]

Another observation is that there are some unhealthy GradleConnector/ProjectConnection reuse mechanism in vscode-gradle, it will create a new daemon every time getProjects() is called.

[mozhuanzuojing]

Taken together, there is no need to change. Because when we obtain information, we need lightweight, fast and real-time services.

[CsCherrYY]

@mozhuanzuojing FYI, we are working on #1088, which will simplify the daemon numbers of the extension. After this change merged, the extension will use only a single daemon all the time, on the other hand, java extension will have its own daemon. This is the first step we work on this issue.