Support mise JDK locations.

[koppor]

Is your feature request related to a problem? Please describe.

I use mise to manage my JDKs. When using //JAVA 24, jbang downloads a JDK and ignores the ones by mise.

Describe the solution you'd like

jbang should use one JDK already downloaded by mise.

Additional context

For gradle, they do not want to support mise directly (gradle/gradle#29355), but work on a general solution: gradle/gradle#29508

[quintesse]

Being able to define your own locations where JDKs could be installed is a nice idea and might be a good feature to add.
I also think it's still a good idea to have a list of well-known locations pre-configured so people don't have to learn how to use this self-configure feature.
This way we'd have the best of both worlds I think.

[wfouche]

to have a list of well-known locations pre-configured

It would be beneficial if SDKMAN JDK locations are supported as well.

Just like when one execute a remote script hosted on Github where you are prompted say if you trust the script to be run locally and can express your level of trust (once, always, etc.); something similar should be done when it comes to downloading a JDK, it would be good if the user is prompted the first time a JDK is to be downloaded with options such as:

(0) Always automatically download JDKs
(1) Allow the user to choose a JDK from JDKs already installed locally (in well-known locations): Mise, SDKMAN, etc.
(2) Provide the PATH to a locally installed JDK in a non-standard directory.
(3) ....

[quintesse]

@wfouche the options you mention are already supported.

You can enable sdkman by running jbang config set jdkproviders all (this will also activate scoop on Windows).

And you can add your own JDKs by running jbang jdk install 17 /path/to/some/jdk17.
(Right now you can have only 1 JDK per major version, 8, 17, 24, etc, that will change in the future)

[wfouche]

the options you mention are already supported.

@quintesse , great to know, thanks!

[quintesse]

I'm still in the process of convincing @maxandersen that enabling these extra providers by default is a good idea wink wink nudge nudge

[koppor]

I would find it amazing if the locations of gg.cmd would be supported.

gg.cmd is an amazing "tool": The same (!) file runs on macOS, Linux, and Windows. It now also has jbang support. Thus, one can run ./gg.cmd jbang run hello@jbangdev world and it downloads jbang and a JDK (if not already available).

https://github.com/eirikb/gg

[maxandersen]

Nice. Haven't seen gg before but if that line works jbang would already know about GG's java from the path/VM jbang is being run with. If that version matches the requested version by User it should just work.

If you meant that jbang would search for additional other jdks wherever gg have put them then that is doable to add with current support today - just need s jdkprovider implementation. Probably best to handle in separate issue / pr.

[maxandersen]

On topic of having jbang automatically and by default search the full list of know jdk locations my hesitance is mainly concerned about it is that it run the risk of breaking consistency of jbangs execution of scripts and slightly secondary that it will add a overhead on startup... But maybe I'm the only one that have enough multiple jdks installed to notice it :)

[quintesse]

@maxandersen I don't think it's that, it's the idea that you could in any way control what JDKs users are going to use to run JBang :-)

We already use whatever JDK is installed on a user's system, as long as it is in the PATH or has JAVA_HOME set. I don't think there will be many people out there that have installed Java using brew, sdkman, gg, foo, bar and baz and that have not changed their PATH/JAVA_HOME. So, even without those providers, we're using "unknown" JDKs anyway!

So not enabling more providers "hurts" those people, in the way that JBang isn't as featureful as it could by allowing them to select JDKs from their favorite package manager. Or if for some reason they don't have their Java in the PATH/JAVA_HOME we'll be downloading an extra JDK when they already have at least one.

And at the same time we're not really helping anyone with the current situation. I have a hard time coming up with any situations where using a JDK from sdkman, brew, etc could cause issues. AFAIK the chance that a user could have a "weird" JDK installed that would somehow make code fail and that JBang would be blamed for that seems really slight.

[koppor]

Currently, the JBang JDK location is .cache/gg/java/java_star_/, because gg.cmd currently works "locally" only without any global cache.

Maybe, there is no need to change anything for gg.cmd, because the environment variables are as follows:

JAVA_HOME=/.cache/gg/java/java_star_
PATH=bin:.:/.cache/gg/java/java_star_/bin:/.cache/gg/java/java_star_/.:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Source: eirikb/gg#86 (comment)

[quintesse]

Sure @koppor , anyone who has their JDK on their PATH or set as JAVA_HOME can use whatever JDK they like. But it won't make it easy to switch between them and other JDKs using JBang. The nice advantage of having better support in JBang for external JDKs is that if you prefer to manage your JDKs using sdkman/brew/gg/etc then you can simply do so and JBang will use them whenever it can.

Btw, you can also "bring in" a JDK by using jbang jdk install <version> <path_to_jdk>, eg jbang jdk 21 /home/user/myjdks/temurin-21.2.3 and you can either use that as your default JDK (by jbang jdk default 21 or whenever code specifies version 21, by using //JAVA 21 or --java 21