JBang should reuse installed SDKMAN JDK (java 25+) instead of downloading another JDK

[ayagmar]

Summary

When running a catalog entry requiring java: 25+, JBang may download a new JDK even if Java 25 is already installed via SDKMAN.

Environment

• OS: 6.19.2-2-cachyos
• SDKMAN installed JDKs:
  • 21-tem (current)
  • 25.0.1-tem
• Command:
  • jbang --verbose run --fresh demos@tamboui --help

Expected

JBang detects and uses installed SDKMAN Java 25 (~/.sdkman/candidates/java/25.0.1-tem) without downloading.

Patch:

Actual

JBang may attempt JDK installation instead of reusing SDKMAN Java 25.

Repro

1. Ensure SDKMAN has Java 25 installed but current Java is 21:
   • ❯ ls -1 ~/.sdkman/candidates/java
   • sdk use java 21-tem
2. Run:
   • JBANG_DIR=$(mktemp -d) jbang --verbose run --fresh demos@tamboui --help
3. Check verbose output for install/download activity.

Root cause (from investigation)

This is in devkitman integration:

• SDKMAN provider not part of basic provider set.
• SDKMAN folder/ID handling needed to support normal SDKMAN folder names while preserving provider-unique IDs.

Proposed fix

• Include sdkman in default/basic provider list.
• Accept SDKMAN folder names like 25.0.1-tem.
• Resolve both suffixed/unsuffixed IDs consistently.
• Ignore current symlink and same-folder duplicates.
• Add tests

Validation

With patched devkitman + jbang:

• Verbose output includes SdkmanJdkProvider.
• Selected JDK is 25.0.1-tem-sdkman at ~/.sdkman/candidates/java/25.0.1-tem.
• No download/install occurs.

I have a working commit, I am happy to open PRs to devkitman + jbang to patch version and align breaking changes ( 0.3 to 0.4 )
Let me know what you think

[quintesse]

Hi @ayagmar , there is already a PR for using version 0.4 of devkitman with all the necessary (and additional) changes: #2271

About your proposed fixes:

• Include sdkman in default/basic provider list. -- That would indeed be my preference as well, but I haven't been able to convince @maxandersen yet
• Accept SDKMAN folder names like 25.0.1-tem. -- I'm not sure I understand the issue, are you saying that the current SDKMAN support in devkitman doesn't support folders like this?
• Resolve both suffixed/unsuffixed IDs consistently. -- I have no idea what you're referring to here. Could you give examples?
• Ignore current symlink and same-folder duplicates. -- I think I understand, but some examples and an explanation why you think the current behaviour should de changed would be most welcome
• Add tests -- More tests are always welcome

All in all, more information and examples on how to reproduce each of the issue you find would help a lot!
Also, if you think the issues are with devkitman, please open them there!

[maxandersen]

Your suggestion is to include sdkman by default?

My stance thus far is that is a user choice because sdkman can have any number of vendors jdks installed thus the choice is not deterministic.

Jbang follows the rule that if user explicitly set up jdkhome or java in PATH we use it (assuming version compatible) or otherwise pick one from Jbang managed installs - which by default is temurin.

Users can configure Jbang to honor more sdk locations - that then falls into the "user explicitly setup".

[quintesse]

Indeed, so the choice is never deterministic anyway. We already accept whatever is currently in the user's environment, so why not SDKMAN (and others)? The "user choice" argument just throws up a roadblock. Nobody ever changes that value. I also just never understood what the supposed downside is. Who cares what vendor gets used? They are all the same basically. And if there is a vendor that would give trouble with JBang or the apps it runs, it would give trouble anyway the moment that Jdk is the user's default (via HOME or PATH).

Edit: I'd almost say: if you're someone who is worried about things "not being deterministic" than you change that value instead of forcing all the rest to have to deal with the question of why JBang isn't picking up our Jdks? :-)

[ayagmar]

Hello @maxandersen
That makes sense and I understand the determinism concern.
But the goal is not “prefer SDKMAN vendor”; it’s only “avoid downloading a new JDK when a compatible one is already installed locally”.

I wanted to try the tamboui demos. My current Java was set to 21, and it threw me off when I saw it try to use bandwidth and download Java 25 even though a usable one already exists. That’s what led me to investigate a bit and open this issue.

While investigating, I noticed selection is already environment-driven (JAVA_HOME / PATH / config). So I think we can keep deterministic precedence while still including SDKMAN as a lowest-priority fallback (since precedence is order-based), e.g.:

current, default, javahome, path, linked, jbang, sdkman

That would only use SDKMAN when earlier providers don’t satisfy the requested version.

---

Hello @quintesse
Sorry I wasn’t concrete enough in my first write-up.

Here are the exact examples from my machine:

~/.sdkman/candidates/java contains:
- 21-tem/
- 25.0.1-tem/
- current -> 21-tem

• Accept SDKMAN folder names like 25.0.1-tem
  Yes, that’s exactly what I meant. SDKMAN’s normal folder names are unsuffixed like 25.0.1-tem, and provider detection/resolution should treat those as first-class installed candidates.

SdkmanJdkProvider had no custom ID/path logic; it just extended BaseFoldersJdkProvider.
BaseFoldersJdkProvider.acceptFolder(...) requires isValidId(folderName).
BaseFoldersJdkProvider.isValidId(...) requires IDs ending with -<providerName>.
For SDKMAN that means the folder must end with -sdkman.

• Resolve suffixed/unsuffixed IDs consistently
  I mean these two identifiers should resolve to the same JDK home:

  • 25.0.1-tem
  • 25.0.1-tem-sdkman
    I guess lookup paths are not always consistent unless this normalization is handled explicitly, would need tests to handle different scenarios

• Ignore current and same-target duplicates
  current is an alias symlink, not a version. If included as a separate candidate, you can end up with duplicate logical entries pointing to the same JDK (current -> 21-tem and 21-tem). This makes listing/selection noisy and can affect behavior.

Also, fair point on repo scope. I hit this while using jbang run ..., so I opened it here first.. In hindsight it should’ve been on the devmankit repo 😄

Edit:

Users can configure Jbang to honor more sdk locations - that then falls into the "user explicitly setup".

If keeping extra SDK locations opt-in is the intended behavior, could we at least improve discoverability at install time?

As a default-config user, I had no idea this setting existed, so it looked like JBang was ignoring an already-installed JDK and downloading another one.

Would you consider this UX if we cant have first class support for sdkman ( as lowest prio ):

• when JBang is about to install JDK 25 (or any version), and running in an interactive terminal, show a prompt like:
  • “No compatible JDK found in enabled providers. You may already have one via SDKMAN/Brew/etc. Enable additional providers now?”
• and print the exact config command to enable them (or a command-specific flag) before proceeding.

[quintesse]

Also, fair point on repo scope. I hit this while using jbang run ..., so I opened it here first.. In hindsight it should’ve been on the devmankit repo

Don't worry. It's all the same project after all. :-) But it's better to track where it actually applies.

Accept SDKMAN folder names like 25.0.1-tem

Aaah, I'm guessing that's something that got broken at some point (I don't actually have Java versions installed with sdkman anymore)
The -sdkman ending is a) needed only for the ID that JBang will use and b) for JDKs that JBang manages itself. Others should of course be able to have custom folder names.
If you want you can open a bug for that on devkitman? Otherwise I'll do it myself soon.

I mean these two identifiers should resolve to the same JDK home:

Ok, but I'm not entirely sure why you think they should resolve to the same? I can understand you might find it somewhat of a nuisance to have longer IDs, but it's not a bug or anything, right? More of a "nice to have"?

Ignore current and same-target duplicates

Probably a good idea. Again, not a bug or anything, so not a high priority.

[wfouche]

My stance thus far is that is a user choice because sdkman can have any number of vendors jdks
installed thus the choice is not deterministic.

JBang by default uses Adoptium, so I would argue that if a JDK with the requested major version number is in the SDKMAN local folder and it has a -tem extension, then use it.

I use SDKMAN even on Windows through Git-Bash.

scoop install git
scoop install curl zip unzip
bash.exe -c "curl -s https://get.sdkman.io/ | bash"

c:\> bash
$ sdk install java 8.0.472-tem
$ sdk install java 25.0.1-tem
$ sdk use java 8.0.472-tem
$ ...

Even here I would like JBang to use one of the Adoptium JDKs that I have already downloaded.

[quintesse]

And I would argue that there is nothing special about Temurin. JBang simply uses it because it's the "community choice". But if the user installed Zulu via SDKMAN I'd also argue that's because they wanted to (SDKMAN doesn't install any by default so the user made that choice).

Looking for -tem installations just makes things more complex and you will still have people complaining saying: "I already have 10 different Zulu versions installed using SDKMAN, why does JBang insist on installing its own??"

[ayagmar]

Yeah but Temurin was only an example from my machine.

My point is vendor-agnostic: if a compatible JDK is already installed via SDKMAN (Zulu, Temurin....), JBang should be able to reuse it instead of downloading another one,

If multiple SDKMAN JDKs satisfy the same java:X+ request, we can keep deterministic behavior with a clear tie-break rule (e.g. provider order, then current, then highest patch version).

Unfortunately as things stand --jdk-provider is not displayed in help even, and when using it it's not compatible with sdkman

[ayagmar]

If you want you can open a bug for that on devkitman? Otherwise I'll do it myself soon.

I have created an issue for this, and also attempted to fix it : jbangdev/jbang-devkitman#95

[ayagmar]

Closing, the sdk provider bug was resolved in jbangdev/jbang-devkitman#96