feat: install multiple JDKs with same major version

[quintesse]

Fixes #2118

[maxandersen]

Interesting. How's it to be used/managed? Couldn't spot clearly the user impact if any?

[quintesse]

The idea is that user impact at first is as close to zero as possible. Mainly to detect if the new system causes any backward compatibility issues.

For the user that is accustomed to installing jdks with jbang jdk install N nothing changes. That command keeps working as before, as does uninstall.

What does change is how jdks are stored on disk. Before you'd just have a bunch of numbered directories in ~/.jbang/cache/jdks, each one containing the jdk for that version, eg:

$ ls -F ~/.jbang/cache/jdks
11/  17/  21/  24/  25/  8/

But now with the new devkitman version you could see this:

$ ls -F ~/.jbang/cache/jdks
11/  17/  21/  24/  25/  26@  26-ea+21-temurin-jbang/  8/

As you can see I just installed a new version 26. And it gets stored in a directory with a full name (its id) and additionally a symlink was created with the name "26" that points to the actual directory.

This symlink serves two purposes: a) is serves as the "default" for that version, so if you have multiple version 26 jdks installed this symlink will point to your "preferred 26 version" and b) it maintains backward compatibility with older JBang versions that will only see the symlinks (older JBang versions ignore directories whose names are not integers).

I still have to make a couple of changes before explaining what else has changed. I will keep you posted in follow-up messages here.

[maxandersen]

gotcha.

and i assume its fine but just asking to know if some limits - on windows the symbolic linking also works ? no extra rights needed etc? in past we "survived" these even without extra rights as jsut one folder but i know some stuff improved here i just forget which :)

And wouldn't it be nicer if stored per vendor?, i.e. / ? or even to simplify have /installs//? just suggesting this to not mix-n-match too much in one folder directly.

whats the signficance of "-jbang" in the name?

[quintesse]

on windows the symbolic linking also works ?

JBang already needs those to work. The default jdk that gets added to your path is a link (a Junction to be precise).

And wouldn't it be nicer if stored per vendor?, i.e. / ? or even to simplify have /installs//? just suggesting this to not mix-n-match too much in one folder directly.

I'm just somewhat following what I see others do. I also think it makes file/folder management slightly more complex to have more levels of directories. Given the fact that nobody should be looking directly at that folder and definitely not depend on its names and structure I feel it's okay to do it this way.

whats the signficance of "-jbang" in the name?

It's because the jdks are managed by the "jbang" provider. There's other providers that can create folders there, for example links to external jdks are handled by the "linked" provider and marked with "-linked".

[quintesse]

@maxandersen this is now ready for review and devkitman 0.4.0 has been released so you don't need to build that to be able to test this PR.

Given the fact that this is a pretty major change it must be tested quite well (I already did of course, but I might be "blind" to certain issues). It must also be tested that older JBang versions keep working even when newer JDKs get installed by this new version.

Also, the workings and output of some of the jdk commands (eg jdk list) have changed somewhat, we might still want to polish that.

[quintesse]

NB: currently releasing 0.4.1 because of a test failure that only appeared when running JBang's GH CI. (Seems GH uses legacy DOS paths in their environment variables, eg. JAVA_HOME=C:\PROGRA~1\Java\jdk11, which devkit handles okay enough except when trying to match it against a modern path)

[maxandersen]

Should I ignore or honor the "do not merge" message ? :)

[quintesse]

Sorry, this PR is ready for review but not ready to merge, I put it back to draft to make that clear.
Any changes I make are to make sure all tests pass and to add some new tests to make sure more things are covered.
But for review purposes (by you) the PR should be good.

[quintesse]

Ok, I marked this PR ready for review again because everything works now. The integration tests are failing because of the Alpine test not being able to download the Jdk 17 it needs, but that's unrelated to this PR.

[quintesse]

Ok, all green, So please go ahead, play around with it and break things :-)

[maxandersen]

i can't get any of the commands to work... doesn't recognize the jdk-providers/jdk-distros ...can't see tests use them either..what am I doing wrong?

[quintesse]

doesn't recognize the jdk-providers/jdk-distros

what do you mean "doesn't recognize"?

I can do the following without issue:

just jbang jdk l --jdk-providers=javahome
just jbang jdk --jdk-providers=javahome l
just jbang run --jdk-providers=javahome echo@jbangdev

And there are tests for --jdk-providers. Not for --jdk-distros indeed , but that's harder to test in the JBang project (because we'd need to actually download stuff and I wanted to avoid that). But in the devkitman project we can properly mock things and it's tested there. But we should indeed come up with some way to test it with jbang itself.

[maxandersen]

ok, it does work now. i got caught up in jdk-vendors vs jdk-distros. good stuff!

[maxandersen]

wait - didnt actually test the multi isntall...

[maxandersen]

I ran just jbang jdk install --force --jdk-distros=graalvm 24 (it wanted --force exactly there - as had already a 24)
but it completed very fast (no download and no output) and I didnt get any linking?

ls -F ~/.jbang/cache/jdks
Permissions Size User Date Modified Name
drwxr-xr-x@    - max  13 Nov  2025   8/
drwxr-xr-x@    - max  23 Oct  2025   11/
drwxr-xr-x@    - max   9 Oct  2025   17/
drwxr-xr-x@    - max   9 Oct  2025   21/
drwxr-xr-x@    - max   7 Jan 10:35   22/
drwxr-xr-x@    - max  28 Dec  2025   24/
drwxr-xr-x@    - max  30 Sep  2025   25/
drwxr-xr-x@    - max  17 Mar 14:21   26/

bug?

[quintesse]

Ok, will look into that.

But what would be the expected result here?

Because I could think of two different interpretations:

1. "Yes, I know I already have a 24, but I also want this one"
2. "Yes, I know I already have a default 24, but I also want this one and I want you to make it the default"

There could even be a 3rd interpretation:

3. "Yes, I know I already have a 24 but I want to use this one instead, so replace existing with this new one"

And depending on the other arguments you pass you might even expect a different result:

• jbang jdk install --force 24 - Option (3)? Because there's a new minor release and you want to update to that one? Although option (2) might also work if we don't want to automatically remove versions
• jbang jdk install --force --jdk-distros=graalvm 24 - Option (1)? Because it's obviously a different one? Or still option (3)? (Or option (2) if we don't want to auto-remove)

Option (1) might be difficult to explain, someone does jbang jdk install --force --jdk-distros=graalvm 24 and then probably expects to be able to run jbang --java 24 graalvmtest.java and not first have to look up the id of the newly installed JDK and use that.

Looking at this option (2) is perhaps the one easiest to explain and giving the least headaches?

[maxandersen]

I assume if i say use Zulu 24 that 24 will give me Zulu.

I think that's what you call option 2.

But this also mean we need someway to say "don't put this as default"

Maybe Jbang jdk install --extra 24 ?

And somehow print what id to use if want to be explicit.

[quintesse]

Not sure, that --extra isn't really an option that makes me "happy", so to speak.

It seems like a fix/workaround that's only useful in very specific situations that will be somewhat hard to explain when to use.

Perhaps combining option (1) with a --default option?

(THe problem might be: the default of what? There is a main/global default and a per-version default. DOes this option mean you want it to become the default for 24 or the main/global default?)

[maxandersen]

How is the current PR intended to be used? it says install multiple jdks with same major version ...whats the command to do that if not jbang jdk install --jdk-provider=zulu 24 ? how to choose which exact version will be installed?

[quintesse]

Well the current PR doesn't yet give you all the options that I have in mind, because the changes were already big enough and I first wanted to get basic functionality working.

Anyway, if you do jdk list -a -d (--available --details) you'll see IDs and you can use those IDs to install exactly that version, eg:

$ jbang jdk list -a -d
   27 (27-ea+17, jbang, 27-ea+17-temurin-jbang, [ea])
   26 (26+35, jbang, 26+35-temurin-jbang)
   25 (25.0.2+10, jbang, 25.0.2+10-temurin-jbang)
   ... etc

And then you can run install 26+35-temurin-jbang to install that exact version.

Right now we don't really show any other options, but you could easily imagine a list that returns options from multiple distros (like sdkman does, for example).

Now that we have the basics working we just have to come up with good ideas and what options/features to add :-)

[quintesse]

For example, one of the things I want to allow is <version>,<tag>... where we now support <version>

Imagine:

• install 24,zulu instead of install --jdk-provider=zulu 24
• install 24,jre,javafx install a version 24 JRE with JavaFx support
• run --java 24+,native run using a 24 or higher GraalVM-based version

PD: I say <version>, but we actually support <version>|<id>, so the new format with tags would also be: <version>,<tag>...|<id>

[maxandersen]

about provider and tags - thats why I was suggesting more structured format, like 24{jre,javafx}@zulu which matches how we been discussing other ways to provide properties to jbang directive syntaxes.

[maxandersen]

#2133 is where that syntax mostly implemented.

[quintesse]

Sure, the actual syntax is irrelevant to devkitman, it's something that would be implemented by JBang itself and then implemented using the existing filtering system.

[quintesse]

I ran just jbang jdk install --force --jdk-distros=graalvm 24 (it wanted --force exactly there - as had already a 24)
but it completed very fast (no download and no output) and I didnt get any linking?

Btw, it seems the current jbang doesn't handle this either.
Still looking into it...

[quintesse]

I ran just jbang jdk install --force --jdk-distros=graalvm 24 (it wanted --force exactly there - as had already a 24)
but it completed very fast (no download and no output) and I didnt get any linking?

@maxandersen this should be fixed now, can you try this new version?