Integrate with SDKMan JDK handling.

[someth2say]

I love how JBang is able to fetch the appropriate JDK distribution if the default does not support the version required in the scripts.
But many times it tries to download distributions I already have available in my local through SDKMan.

It would be interesting if JBang could detect SDKMan available in the system, and delegate to it (maybe through sdk env) to activate the needed JDK version in the current shell.

Thoughts?

[maxandersen]

The challenge is I cant see how we can do this reliably.

I.e. last I looked sdkman don't have a notion of getting latest major version; ie. Give me latest java 17..

Jbang does honor whatever is configured in the system first so you can use sdkman or anything else to manage sdk outside jbang.

Maybe what you would want is way to avoid jbang auto downloads ? And instead fails if download needed ?

[quintesse]

One possible solution would be to have an option where the jdk handling is delegated to an external script/executable. Let's say for example that we check if a script/executable named jbang-jdk exists and we could use it to determine the path to a JDK using for example jbang-jdk home X which would return the path to JDK version (which on purpose is what the jbang jdk home command does as well). But more importantly the script could install that version if it was missing.

(PS: Ideally we would be able to use the same system for our own built-in jdk handling, perhaps by leveraging the plugin system)

[maxandersen]

we could but it would:

1. not apply for the case where you install jbang first and no jvm 8+ in path
2. make jbang jdk home inconsistent as it would not list the jdks installed this "other way"
3. not "just work" on windows with sdkman
4. it need to be an opt-in as we need to work by default without the external script being available

#3 is my biggest issue and major reason as we will by this have quite different behaviors and how do we deal with different jvm package managers on the OS? we would need to be bundling different scripts to make it a good experience.

I'm open for PR that makes it a config option you can enable to relay the fetching of JDK's via a script in case system available jvm does not match the need; but I don't see it becoming the default.

[quintesse]

1. When I say "script/executable" I was thinking about a shell script or even an executable. So not a JBang script because then we'd in fact have a chicken and egg problem.
2. Well no, the idea is that all jbang jdk commands would delegate to this script/executable. (You'd basically "lose" the ability to install JDKs in the standard JBang way)
3. Sure, somebody on Windows would not install the SDKMAN version of the script, but could chose the Scoop or Chocolate version instead.
4. My idea was that this would be opt-in indeed, it would just be for people who really want integration with their local package manager. We would definitely keep our own manager by default.

But... I can see our own manager just using the same system, it would remove the duplication of code we have now both in the startup scripts and in the Java code. But it definitely is not a required feature, no.

[maxandersen]

1. When I say "script/executable" I was thinking about a shell script or even an executable. So not a JBang script because then we'd in fact have a chicken and egg problem.

yes, only considered script here about shell script or executable - but even then we wont have the scripts available to us before jbang installed so I cannot see how we can utilize it to download the very initial jdk.

2. Well no, the idea is that all `jbang jdk` commands would delegate to this script/executable. (You'd basically "lose" the ability to install JDKs in the standard JBang way)

No, I don't see how that is an option. On first run we need to be able to get a JDK with 99.99% guaranty - relying on different approaches on different OS's won't fly.

sdkman does NOT have all versions available nor is there a ordering ...similar with scoop and choco - they will require slightly different mechanics thus we must default to most reliable approach (which is what we have now).

3. Sure, somebody on Windows would not install the SDKMAN version of the script, but could chose the Scoop or Chocolate version instead.

Choose when ? it wont be available by default.

4. My idea was that this would be opt-in indeed, it would just be for people who really want integration with their local package manager. We would definitely keep our own manager by default.

Yes, so I think we agree - this is pure optional and won't be the default behavior.

But... I can see our own manager just using the same system, it would remove the duplication of code we have now both in the startup scripts and in the Java code. But it definitely is not a required feature, no.

I don't see how due to above reasons - primarily you can't know which package manager on the OS to use.

[someth2say]

I like the idea of delegating the SDK management to a script/executable/plugin/whatever.

My 5 cents:

1. not apply for the case where you install jbang first and no jvm 8+ in path

Agree. I feel those are different use cases. One is "how to make a JVM available to run JBang" and the other is "how to make a JVM available to run this script".
The first one must be resolved by a "universal" system, so JBang can run anywhere (now solved by https://github.com/jbangdev/jbang/blob/main/src/main/scripts/jbang#L156). The second one delegates to an external script/executable/plugin in the local system that takes care of it.

2. make jbang jdk home inconsistent as it would not list the jdks installed this "other way"

In my mind, if there is a jdk-manager-plugin (whatever the name is) configured, all jbang jdk commands should be delegated to the plugin. The plugin must provide the list of jdk's or the jdk home.

3. not "just work" on windows with sdkman

As @quintesse proposed, Windows users shall not use the jdk-manager-sdkman plugin, but jdk-manager-chocolatey or jdk-manager-scoop.

4. My idea was that this would be opt-in indeed, it would just be for people who really want integration with their local package manager. We would definitely keep our own manager by default.

Agree with that. The usage of any plugin would be indeed optional.
At some point, JBang could detect the presence of SDKMan, Chocolatey, Brew... and propose users to deploy the appropriate plug-in. But that would be a nice-to-have for the future.

[quintesse]

1. When I say "script/executable" I was thinking about a shell script or even an executable. So not a JBang script because then we'd in fact have a chicken and egg problem.

yes, only considered script here about shell script or executable - but even then we wont have the scripts available to us before jbang installed so I cannot see how we can utilize it to download the very initial jdk.

Just like we do now: before we do anything we first download JBang itself if necessary (the curl/iex/zero-conf way) and only then do we download the required JDK. That means that the full JBang code is available on the system before we check for any JDKs. Which means we could easily have a script inside our JBang download that does exactly what we do now inside our startup scripts and with jbang jdk.

I'll make a simple PoC some day to convince you it's possible :-) (but first 1.0)

2. Well no, the idea is that all `jbang jdk` commands would delegate to this script/executable. (You'd basically "lose" the ability to install JDKs in the standard JBang way)

No, I don't see how that is an option. On first run we need to be able to get a JDK with 99.99% guaranty - relying on different approaches on different OS's won't fly.

If the user didn't specifically override our default then we'd still use our own mechanism, just inside a separate script instead of inside the startup scripts and inside jbang itself.

sdkman does NOT have all versions available nor is there a ordering ...similar with scoop and choco - they will require slightly different mechanics thus we must default to most reliable approach (which is what we have now).

Sure, I get that. The script developer would have to think about what to do when a script asks for a version it can't deliver. I'm guessing option 1 is to just take the next higher version that is available and if there isn't a higher version they should probably just display an error. That's just what happens when you chose a different provider IMO. (Very important this, the user explicitly requested a different provider! This is not about trying to detect and automatically use a different provider)

3. Sure, somebody on Windows would not install the SDKMAN version of the script, but could chose the Scoop or Chocolate version instead.

Choose when ? it wont be available by default.

Well in whatever way we decide to make it available. It could be something (relatively) complicated as downloading a script and manually copying it in your PATH, or perhaps we will distribute scripts for SDKMAN, Choco and Scoop with JBang and the user would have to configure which one to use. (Always defaulting to our implementation of course)
I can think of all kinds of ways :-)

4. My idea was that this would be opt-in indeed, it would just be for people who really want integration with their local package manager. We would definitely keep our own manager by default.

Yes, so I think we agree - this is pure optional and won't be the default behavior.

But... I can see our own manager just using the same system, it would remove the duplication of code we have now both in the startup scripts and in the Java code. But it definitely is not a required feature, no.

I don't see how due to above reasons - primarily you can't know which package manager on the OS to use.

What I mean with this last remark is that I could see us removing our JDK handling from the startup scripts and from the Java code and move it to a script. That script would then be the JDK handler JBang uses by default if the user doesn't configure another one. So the behavior stays exactly the same, just the implementation changes.

[quintesse]

Btw, there's already an issue for this: #316