feat: install multiple JDKs with same major version by quintesse · Pull Request #2271 · jbangdev/jbang

quintesse · 2025-11-04T21:38:03Z

maxandersen · 2025-11-04T22:58:17Z

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

quintesse · 2025-11-05T09:47:45Z

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 · 2025-11-05T11:59:38Z

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 · 2025-11-05T13:54:04Z

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 · 2026-01-16T09:01:47Z

@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 · 2026-01-16T18:22:06Z

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 · 2026-01-19T11:04:09Z

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 · 2026-01-20T11:44:00Z

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 · 2026-03-04T14:42:20Z

I run:

just jbang --jdk-vendors donotexist --java 21 properties@jbangdev java

and it runs java 21...is that expected? should it not tell me I don't have a java 21 with that vendor?

maxandersen · 2026-03-04T14:43:50Z

sorry no, jdk-vendors is just of IFF the java version string isn't available.

quintesse · 2026-03-04T15:19:18Z

Jdk vendors is not used for running, it's only used for installing and listing jdks available for installation (yes, that flag should perhaps be moved to the list and install commands, but the config is global, and overriding the global config per command is somewhat complicated. I'll have to take a look how to improve that. For now it should at least not cause any issues)

quintesse · 2026-03-04T19:36:19Z

yes, that flag should perhaps be moved to the list and install commands

Ah no, we can't, because of course if you run jbang run --java XX foo@bar an d you don't have XX installed you would want to be able to affect where that XX comes from.

Now, we'd probably prefer a theoretical new syntax where you could simply say XX,zulu. But you still want to be able to set a config variable that tell JBang which vendors you prefer. And for that we still need that --jdk-vendors flag.

maxandersen · 2026-03-04T22:52:43Z

trying to follow the logic here:

jbang jdk --jdk-vendors=zulu list -a
   26 (26-ea+28-zulu-jbang)
   25 (25.0.2+10-zulu-jbang)
   24 (24.0.2+12-zulu-jbang)
   23 (23.0.2+7-zulu-jbang)
   22 (22.0.2+9-zulu-jbang)
   21 (21.0.10+7-zulu-jbang)
   20 (20.0.2+9-zulu-jbang)
   19 (19.0.2+7-zulu-jbang)
   18 (18.0.2+9-zulu-jbang)
   17 (17.0.18+8-zulu-jbang)
   16 (16.0.2+7-zulu-jbang)
   15 (15.0.10+5-zulu-jbang)
   13 (13.0.14+5-zulu-jbang)
   11 (11.0.30-zulu-jbang)
   8 (8.0.482-zulu-jbang)

jbang jdk --jdk-vendors=zulu,temurin list -a
   27 (27-ea+11-temurin-jbang)
   26 (26-ea+28-zulu-jbang)
   25 (25.0.2+10-zulu-jbang)
   24 (24.0.2+12-zulu-jbang)
   23 (23.0.2+7-zulu-jbang)
   22 (22.0.2+9-zulu-jbang)
   21 (21.0.10+7-zulu-jbang)
   20 (20.0.2+9-zulu-jbang)
   19 (19.0.2+7-zulu-jbang)
   18 (18.0.2+9-zulu-jbang)
   17 (17.0.18+8-zulu-jbang)
   16 (16.0.2+7-zulu-jbang)
   15 (15.0.10+5-zulu-jbang)
   13 (13.0.14+5-zulu-jbang)
   11 (11.0.30-zulu-jbang)
   8 (8.0.482-zulu-jbang)

   27 (27-ea+11-temurin-jbang)
   26 (26-ea+28-zulu-jbang)
   25 (25.0.2+10-zulu-jbang)
   24 (24.0.2+12-zulu-jbang)
   23 (23.0.2+7-zulu-jbang)
   22 (22.0.2+9-zulu-jbang)
   21 (21.0.10+7-zulu-jbang)
   20 (20.0.2+9-zulu-jbang)
   19 (19.0.2+7-zulu-jbang)
   18 (18.0.2+9-zulu-jbang)
   17 (17.0.18+8-zulu-jbang)
   16 (16.0.2+7-zulu-jbang)
   15 (15.0.10+5-zulu-jbang)
   13 (13.0.14+5-zulu-jbang)
   11 (11.0.30-zulu-jbang)
   8 (8.0.482-zulu-jbang)

15 with zulu, 12 with termurin, 16 with temurin,zulu (or zulu,temurin)

..so this is showing all major java versions, if available, ordered by vendors?

...I see --details gives the "true" all...now...whats the expected list of vendors ?

quintesse · 2026-03-04T23:00:24Z

.so this is showing all major java versions, if available, ordered by vendors?

Yes, something like that. It's following the same we do right now. You have to imagine that by default our setting for vendors is "temurin,aoj" (preference given to temurin for being first in the list). And in that case doing list -a does the same: it gives only a single option per major version. (We could change that of course, but then it would change for the default as well. So then you're left wondering: "I see 2 JDK 17s, which one will get installed when I do install 17?)

When you ask for details no filtering is performed.

maxandersen · 2026-03-20T05:58:17Z

@quintesse are the failures easily fixable or we wait?

maxandersen · 2026-04-02T20:48:36Z

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

maxandersen · 2026-04-02T21:13:54Z

seems to be wiremock related maybe?

maxandersen · 2026-04-13T06:46:52Z

src/main/java/dev/jbang/cli/JdkProvidersMixin.java

 import picocli.CommandLine;

 public class JdkProvidersMixin {
+	protected static List<String> jdkProviders;


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?

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;

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.

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

Fixes jbangdev#2118

Added a flag `--for-version` (or `-v`) to the `jdk default` command to allow setting the default Jdk to use for a specific major version. This is necessary now that we allow multiple Jdks of the same major version to be installed simultaneously.

Added some more parameter checks to `jdk install`. Also refactored `Jdk` class.

quintesse force-pushed the devkitman_multi_jdks branch from 14d6edb to 9f510d6 Compare November 4, 2025 21:43

quintesse force-pushed the devkitman_multi_jdks branch 2 times, most recently from 6decb1a to db613f3 Compare November 20, 2025 15:04

quintesse force-pushed the devkitman_multi_jdks branch from db613f3 to 3e306cf Compare December 12, 2025 17:43

quintesse force-pushed the devkitman_multi_jdks branch 2 times, most recently from 3a2a8c8 to 8aeb565 Compare January 16, 2026 08:50

quintesse marked this pull request as ready for review January 16, 2026 08:50

quintesse requested a review from maxandersen January 16, 2026 08:52

quintesse force-pushed the devkitman_multi_jdks branch 3 times, most recently from 0ac3adf to 056cbeb Compare January 16, 2026 20:05

maxandersen reviewed Jan 16, 2026

View reviewed changes

quintesse marked this pull request as draft January 19, 2026 11:01

quintesse force-pushed the devkitman_multi_jdks branch 5 times, most recently from 25edf97 to f5e2801 Compare January 20, 2026 11:29

quintesse marked this pull request as ready for review January 20, 2026 11:42

quintesse force-pushed the devkitman_multi_jdks branch from f5e2801 to fc85039 Compare January 20, 2026 16:00

quintesse mentioned this pull request Feb 19, 2026

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

Closed

quintesse force-pushed the devkitman_multi_jdks branch from fc85039 to 2ad3d27 Compare March 4, 2026 13:50

quintesse force-pushed the devkitman_multi_jdks branch 2 times, most recently from 660d050 to b13b12c Compare March 26, 2026 13:14

maxandersen reviewed Apr 13, 2026

View reviewed changes

quintesse added 5 commits April 13, 2026 10:07

feat: install multiple JDKs with same major version

e9f1608

Fixes jbangdev#2118

feat: added --jdk-installer option

3c6c243

Added some more parameter checks to `jdk install`. Also refactored `Jdk` class.

feat: can now list providers and distros

b6f9f29

chore: updated native image configuration

0ae7d47

quintesse force-pushed the devkitman_multi_jdks branch 2 times, most recently from b37d7f4 to 7d835a7 Compare April 13, 2026 08:08

chore: fixed tests

48e9356

quintesse force-pushed the devkitman_multi_jdks branch from 7d835a7 to 48e9356 Compare April 13, 2026 11:14

Uh oh!

Conversation

quintesse commented Nov 4, 2025

Uh oh!

maxandersen commented Nov 4, 2025

Uh oh!

quintesse commented Nov 5, 2025

Uh oh!

maxandersen commented Nov 5, 2025

Uh oh!

quintesse commented Nov 5, 2025

Uh oh!

quintesse commented Jan 16, 2026

Uh oh!

quintesse commented Jan 16, 2026

Uh oh!

maxandersen left a comment

Choose a reason for hiding this comment

Uh oh!

quintesse commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

quintesse commented Jan 20, 2026

Uh oh!

maxandersen commented Mar 4, 2026

Uh oh!

maxandersen commented Mar 4, 2026

Uh oh!

quintesse commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

quintesse commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maxandersen commented Mar 4, 2026

Uh oh!

quintesse commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maxandersen commented Mar 20, 2026

Uh oh!

maxandersen commented Apr 2, 2026

Uh oh!

maxandersen commented Apr 2, 2026

Uh oh!

maxandersen Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

quintesse Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

quintesse Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maxandersen Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

quintesse commented Jan 19, 2026 •

edited

Loading

quintesse commented Mar 4, 2026 •

edited

Loading

quintesse commented Mar 4, 2026 •

edited

Loading

quintesse commented Mar 4, 2026 •

edited

Loading

quintesse Apr 13, 2026 •

edited

Loading