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.

[maxandersen]

@quintesse any idea of why the new devkitman seem to fail handling idk 11 and other installs?

[maxandersen]

seems to be wiremock related maybe?

[maxandersen]

did you mean these to be static? they depend on arguments set on command line so sure can be static, but what if/when run during tests?

[quintesse]

But aren't the tests run sequentially?
Because if this is an issue we will have problems with all of these as well:

	private static boolean verbose;
	private static boolean quiet;
	private static boolean offline;
	private static boolean fresh;
	private static boolean ignoreTransitiveRepositories;
	private static boolean preview;

[quintesse]

Ah yes, I remember now why they are static. It's because the options can be set on different "levels", if you type jbang jdk --jdk-providers list or jbang jdk list --jdk-providers the option gets handled by a different instance of the JdkProvidersMixin (and you could even mix! Imagine jbang jdk --jdk-distros xxx list --jdk-providers yyy, one option would be set in one instance and the other in a second instance). This makes figuring out what options to actually use much harder than it needs to be. So switching to static "fixes" that.

It's definitely not thread-safe, but the cli commands are not designed to be.

Our project compiler/builder API is much more thread-safe in this respect, but it still uses the static fields I mentioned above. That might be something we'd want to fix at some point.

[maxandersen]

but shouldn't we then use picocli @parentcommand or scopetype = inherited?

[maxandersen]

opened quintesse#152 with pr that i think shows and fix the issue

[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>