Can we reference an external build of JDT-LS ?

[mickaelistria]

Hi,
I'm trying to test changes in upstream JDT or m2e down to VSCode-Java. As I have JDT-LS code locally and am comfortable playing with it, I can produce a JDT-LS build with the desired content.
Now I'm looking for a way to get VSCode-Java using this local build without having to build/install a local extensions and without tweaking the default deployment (I'd like to avoid playing with the internal filesystem of the extension to replace the server/ folder with alternative content or a symlink, so I keep easy access to default behavior by default). Ideally, I would hope for an environment variable I can set to reference an alternative location for JDT-LS and would use it when starting VSCode for testing purpose.
I couldn't find anything allowing to easily achieve that in the code; but I'm not much fluent with the codebase, so maybe I missed something... Did I miss something? If not, I will open an issue to suggest such a env variable for easier testing.

[rgrunber]

There is no way to refer to another JDT-LS instance without either rebuilding a new vsix (probably the easiest way), or without replacing the contents of the installation location (eg. $HOME/.vscode/extensions/redhat.java-1.20.2023060904-linux-x64/server) .

I'm not sure why either of the above approaches isn't enough, given that all of the state-based information/settings are stored in completely different areas. We could make a setting in vscode-java itself to allow using some external JDT-LS, but it seems unnecessary.

[mickaelistria]

So I can remove $HOME/.vscode/extensions/redhat.java-1.20.2023060904-linux-x64/server , use my own build, remove it again and vscode-java would restore it to vanilla version on next startup?

[rgrunber]

This could work. You would also need to clear out the Eclipse config location, which is set for $HOME/.config/Code/User/globalStorage/redhat.java/1.20.2023060904/config_linux (as an example). This for example contains :

$ ls -1
config.ini
org.eclipse.core.runtime
org.eclipse.equinox.app
org.eclipse.equinox.launcher
org.eclipse.osgi

as well as any nested jar bundles that need to be placed here (mainly from m2e).

[snjeza]

@mickaelistria @rgrunber You can also try the following:

• import Java LS in Eclipse - B) Setting up the JDT Language Server in Eclipse
• run the jdt.ls.socket-stream.launc launch configuration in Eclipse
• run Launch extension - JDTLS Client in VS Code

You don't have to build Java LS. You can debug Java LS, use Hot code replace (HCR)...

[rgrunber]

@mickaelistria's use-case is basically : "As a developer of Upstream Eclipse components & JDT-LS, I want to test on VS Code without having to build any VS Code extensions (no npm setup or any of that). The "launches" on the vscode-java side would require some setup.

[mickaelistria]

I've submitted #3152 to achieve that and could use it recently. I confirm that this approach is by far simpler and more efficient than other recommended ones for my case and would see a clear benefit in having it enabled when working further on JDT-LS, as VSCode is not my main target but I want to easily test/demo it.

[rgrunber]

This has been merged, and described at https://github.com/redhat-developer/vscode-java/blob/master/CONTRIBUTING.md#c-3-set-location-to-a-local-copy-of-jdt-ls .