java core plugin: add support for macOS JAVA_HOME

[roele]

On macOS, some tools rely on the build in /usr/libexec/java_home to evaluate installed Java Versions. Most distributions of Java SDKs (except liberica AFAIR) ship with the necessary additional files (Info.plist, macOS) to integrate with macOS.

To get this feature working with the current java core plugin the installation process needs to change slightly. The unarchived package should not skip any files or fold the structure for macOS. Additionally on macOS if the vendor supports it, a symlink in /Library/Java/JavaVirtualMachines should be created to enable the integration. A hindrance to creating this symlink is, that it requires administrative privileges (therefore sudo), an error hinting to use sudo should be displayed. This feature could be made available via setting the environment variable RTX_JAVA_MACOS_INTEGRATION=true.

[cosminstefanxp]

Hello. Could you please clarify how is this supposed to work? If installing a new version (e.g. mise use -g java@zulu-17) no links are automatically added to /Library/Java/JavaVirtualMachines.

Furthermore, the step described here doesn't work nicely, since the installation folder is, for example: .local/share/mise/installs/java/zulu-17.46.19. Which means everytime the java version updates, the link would need to be updated, since I don't have a simple folder like .local/share/mise/installs/java/zulu-17, even though I install zulu-17.

[roele]

@cosminstefanxp Mise can not automatically create the links since macOS requires sudo on these directories. Also not all vendors support macOS integration (requires additional files). Hence it was decided to leave managment of these symlinks to the user. Mise just prints a hint for vendors supporting the integration.

  ❯ mise install java@adoptopenjdk-17.0.9+9
mise To enable macOS integration, run the following commands:
sudo mkdir /Library/Java/JavaVirtualMachines/adoptopenjdk-17.0.9+9.jdk
sudo ln -s ~/.local/share/mise/installs/java/adoptopenjdk-17.0.9+9/Contents /Library/Java/JavaVirtualMachines/adoptopenjdk-17.0.9+9.jdk/Contents

openjdk version "17.0.9" 2023-10-17
OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode)

[jdx]

we generate fuzzy version dirs like ~/.local/share/mise/installs/node/20. This logic doesn't work for java since it currenty only works for simple semver versions and the "zulu-" prefix it doesn't know how to work with. This could probably be fixed by hardcoding support for java sdk names.

[cosminstefanxp]

@roele , it seems the hints are not generated for all vendors, even though they support it. E.g.:

➜  ~ mise install java@zulu-11
openjdk version "11.0.21" 2023-10-17 LTS
OpenJDK Runtime Environment Zulu11.68+17-CA (build 11.0.21+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.68+17-CA (build 11.0.21+9-LTS, mixed mode)
mise java@zulu-11.68.17 ✓ installed

Would it be possible to ask for sudo access during installation? Or upgrade?

[cosminstefanxp]

@jdx , with regards to the fuzzy version dirs, the fact that this support is missing for other vendors (and I'd like to add that other vendors are actually the most used and recommended, while openjdk, the default, is not: https://whichjdk.com/), is a big pain. Manually updating symlinks everytime there's an update is very problematic, as they typically release patch versions quite often.

Would it be possible to enhance support for more complex versions? Or switch to a different, yet supported semver, such as java@17+zulu? Or go for hardcoding at least the major JDK providers?

[roele]

@cosminstefanxp Just noticed that Zulu distributions do not show the hint and provided a fix with #1381. IMO asking for sudo access is not feasible since this might affect countless other areas (caching, ...). Adding support for fuzzy versions might be an option though.

[jdx]

oh sorry I forgot we have those special sdk directories

[jdx]

yeah to add some context around the sudo thing, we talked about it but my concern is that someone runs "sudo mise ..." and it creates internal files that only sudo has access to, then you'll get warnings/errors the next time you run it without sudo.

I'm fairly certain this use-case is the only one where we've ever wanted to use sudo in mise. If that changes and we have more, perhaps this decision could be revisited by making the CLI behave differently under sudo, but that's not to be taken lightly since it would affect the entire codebase for seemingly unrelated things.

[jdx]

maybe there might be room for a totally separate CLI like mise-sudo or something that wouldn't do as much and we'd therefore be comfortable running under sudo. Or a bespoke thing for this purpose like mise-java-home.

[roele]

I think (at this point at least) a separate CLI would be a bit overkill. I personally use a couple functions in my fish shell that serve as a wrapper around /usr/libexec/java_home to deal with macOS Java and allow me to easily list/set/link/unlink JDKs as required.