Metals caches path to java

[kurnevsky]

Describe the bug

Metals caches path to java in ~/.bloop/bloop.json and then uses it to start bloop. It's not always correct thing to do. For instance, in NixOS I get the following value of this file: {"javaHome":"/nix/store/mir2hanra9zc3cmn8h78insschpxdg0i-openjdk-17.0.3+7/lib/openjdk"}, i.e. it cached path to nix store which might change after NixOS update. This leads to the error java.io.IOException: Cannot run program "/nix/store/h6f224sdr2iqmcscrbywylsr9q2qhj7m-openjdk-17.0.3+7/lib/openjdk/bin/java" when starting metals.

Expected behavior

No response

Operating system

Linux

Editor/Extension

Emacs (lsp-metals)

Version of Metals

0.11.6

Extra context or search terms

nixos java bloop

[tgodzik]

Thanks for reporting!

What should be the correct path here? How do you set it up for metals? Is there any stable path that can be used?

We changed metals to save that java path in order to have the same one between Bloop and metals.

We could special case nix, but not sure If that is the correct way to do it.

[kurnevsky]

I didn't configure this path anyhow, metals got it by itself. I'd expect it not to cache this path at all (unless I explicitly ask this) or at least to use java from $PATH, in case of nixos which java gives /run/current-system/sw/bin/java - this path is not changed with system updates.

[kurnevsky]

Probably metals just followed the symlink /run/current-system/sw/bin/java -> /nix/store/mir2hanra9zc3cmn8h78insschpxdg0i-openjdk-17.0.3+7/bin/java?

[dos65]

@tgodzik I'm thinking that instead of writing into a config we can extends bloopgun and pass the javaHome and options as arguments.

[tgodzik]

@tgodzik I'm thinking that instead of writing into a config we can extends bloopgun and pass the javaHome and options as arguments.

Then the users running Bloop from CLI could have different JVM. Config is the safest place currently, though it would probably be best if bloopgun downloaded the Java instance itself and defaulted to latest LTS + release flags.

[dos65]

Config is the safest place currently, though it would probably be best if bloopgun downloaded the Java instance itself and defaulted to latest LTS + release flags.

@tgodzik if the plan is to prepare to switch to jdk17 we anyway need to download it before starting Metals(run both metals-server and bloop on jdk17+). In this case, the approach with passing jvmHome would work well.

The only non-compat case might came from bloop-cli users but I think we can detect it on Metals side.

Config thing isn't reliable enough. The same problem with bloop-cli might happen not only in case of NixOS. For example, you have a jdk11, then you decide to install another version and delete the previous one.

[kurnevsky]

though it would probably be best if bloopgun downloaded the Java instance itself and defaulted to latest LTS + release flags.

NixOS is not FHS system, so downloaded binaries don't work here in most cases, without additional patching or environment setup. So if this happens can we have an option to use system java? :)

btw, apple M1 processor have problems with downloading binaries too.

[tgodzik]

Bloop already downloads a bunch of things such as the compiler bridges, doesn't it currently cause any issues?

[kurnevsky]

It doesn't since it's jar that's executed by system jvm. But native ELF binary will have problems, which is the case if we download java itself. Same way coursier native binaries have problems, see emacs-lsp/lsp-metals#68

[kpodsiad]

@tgodzik what is current state of this issue? Will it be resolved before next release? Currently, every Java update which removes old one is causing problems.

[tgodzik]

I haven't yet figured out how to fix it properly. A workaround would be to specify the java home in Bloop yourself and ignore the notification (this will get saved in the next version).

[tgodzik]

@kurnevsky is there any way we can infer java home in your case? Is it available via JAVA_HOME for example?