Currently, we use a combination of locate-java-home and Jabba to get Metals with Java setup. However, both of those options are not very well maintained.
Instead, I think we should work out a much more stable approach with Metals using its' own JVM.
This can be done using coursier, which would make us reuse any Java that was previously downloaded using it or via Scala CLI.
We would need to follow these steps:
Check if coursier is on PATH (this is already implemented) and if not try to download the native image (as explained https://get-coursier.io/docs/cli-installation#native-launcher). We should make sure that it's not downloaded every time. We could possibly have a version inside the repo and update it when releasing. The cs executable can be kept in the metals extension directory.
Download Java cs java --jvm 17 --setup
Check Java Home cs java-home --jvm 17
Start metals with that Java Home
Bloop should use the exact same Java Home.
We should add a simple setting that allows user to choose JVM version for Metals itself. (8/11/17/21) currently and ideally (17/21) later on when we migrate to new sockets in Metals server.
javaHome setting would only be used for running bloopInstall or bsp launchers.
Questions:
should we still try to find JAVA_HOME? This might be a bit complex as it would require us to check the version of the particular java manually.
Currently, we use a combination of
locate-java-homeand Jabba to get Metals with Java setup. However, both of those options are not very well maintained.Instead, I think we should work out a much more stable approach with Metals using its' own JVM.
This can be done using coursier, which would make us reuse any Java that was previously downloaded using it or via Scala CLI.
We would need to follow these steps:
cs java --jvm 17 --setupcs java-home --jvm 17Questions: