Bloop doesn't use JAVA_HOME unless `--bloop-jvm system` is set (M1 mac)

Version(s)

0.1.7, it’s been the case in earlier versions as well

Describe the bug

When using scala-cli v0.1.7 from the Releases page, even though JAVA_HOME points to an openjdk17, I still have to pass --bloop-jvm system for it to use what JAVA_HOME points to.

I believe https://github.com/VirtusLab/scala-cli/pull/781 was supposed to solve this problem, but for some reason… doesn’t. It still uses temurin in an x86 variant even though it’s running on an M1 mac.

Here’s the output of $JAVA_HOME/bin/java -version I’m getting.

openjdk version "17.0.3" 2022-04-19 LTS
OpenJDK Runtime Environment Zulu17.34+19-CA (build 17.0.3+7-LTS)
OpenJDK 64-Bit Server VM Zulu17.34+19-CA (build 17.0.3+7-LTS, mixed mode, sharing)

To Reproduce

1. Get openjdk17 from zulu (e.g. from Nixpkgs)
2. Get the scala-cli binary: https://github.com/VirtusLab/scala-cli/releases/download/v0.1.7/scala-cli-x86_64-apple-darwin.gz
3. export JAVA_HOME=<wherever the jdk is>
4. Create a foo.sc file with anything
5. ./scala-cli compile foo.sc
6. Check running processes to see which JVM is used

Expected behaviour

The JVM that JAVA_HOME points to is used.

[lwronski]

Thanks for reporting @kubukoz, there was a problem that scala-cli couldn’t resolve JAVA_HOME for a native launcher built by GraalVM, because ScalaCLI read java.home from properties which return None.

So we fixed it and now scala-cli read JAVA_HOME from path, and then if not found, then try to find JAVA_HOME in properties.

In the next version of scala-cli 0.1.8 it should be fixed 1084.

If you want to test it now, you can download snapshot native launcher of Scala CLI from Artifacts.

[kubukoz]

It’s all good in 0.1.8, thanks 😃