Fuzzy match java distributions

[Dogacel]

Fuzzy matching java distributions can be very useful. We share our .tool-versions files in github repositories. I usually prefer using temurin based java in my local, but other developers choose corretto based distributions.

However I don't mind which java distribution I use, I just want to have a single installation for a specific JDK version, and I want it to work by default.

[jdx]

we have fuzzy matching for java, it just doesn't work for temurin and possibly others I believe because our semver library can't parse temurin. I definitely remember testing corretto though and it was working.

We either need to modify the fuzzy matching logic to work with temurin versions explicitly somehow or have a way for plugins to provide their own logic around version matching.

[Dogacel]

we have fuzzy matching for java, it just doesn't work for temurin and possibly others I believe because our semver library can't parse temurin. I definitely remember testing corretto though and it was working.

We either need to modify the fuzzy matching logic to work with temurin versions explicitly somehow or have a way for plugins to provide their own logic around version matching.

I think we can use a regex like this?

[(adoptopenjdk-jre)|(adoptopenjdk)|(corretto)|(graalvm)...]{0, 1}$VERSION_REGEX

Or something more generic

(\w-)*$VERSION_REGEX

And of course also update version regex so it supports temurin's (and others) too.

\d(\.\d)+(\+\d?)(\.LTS?)

[jdx]

have at it: https://github.com/jdx/mise/blob/main/src/runtime_symlinks.rs#L39

[roele]

However I don't mind which java distribution I use, I just want to have a single installation for a specific JDK version, and I want it to work by default.

As i see it, this will not work relyably since the versions used are vendor versions and not Java versions. So they might not be interchangeable between vendors in every case.

For example if you want a JDK version 20.0.2, this would not work with Azul.

mise ls-remote java@temurin-20
temurin-20.0.0+36
temurin-20.0.1+9
temurin-20.0.2+9

mise ls-remote java@zulu-20
zulu-20.28.85 (20.0.0)
zulu-20.30.11 (20.0.1)
zulu-20.32.11 (20.0.2)
zulu-20.32.11_1 (20.0.2)

[Dogacel]

However I don't mind which java distribution I use, I just want to have a single installation for a specific JDK version, and I want it to work by default.

As i see it, this will not work relyably since the versions used are vendor versions and not Java versions. So they might not be interchangeable between vendors in every case.

For example if you want a JDK version 20.0.2, this would not work with Azul.

mise ls-remote java@temurin-20

temurin-20.0.0+36

temurin-20.0.1+9

temurin-20.0.2+9

mise ls-remote java@zulu-20

zulu-20.28.85 (20.0.0)

zulu-20.30.11 (20.0.1)

zulu-20.32.11 (20.0.2)

zulu-20.32.11_1 (20.0.2)

Wait why it wouldnt work in this case? Zulu-20.xxx and temurin-20.xxx are both jdk 20?

[roele]

@Dogacel Depends on your interpretation of fuzzy-matching. It would work for major versions. I assume minor, patch would be rarely used in such a way anyways. Additionally Azul seems to be the only outlier with different minor/path versioning.

[Dogacel]

@Dogacel Depends on your interpretation of fuzzy-matching. It would work for major versions. I assume minor, patch would be rarely used in such a way anyways. Additionally Azul seems to be the only outlier with different minor/path versioning.

I did not assume minor version matching for cross-vendors. I personally don't see any difference between using zulu-20.28 or temurin-20.0.2 and that was the whole point I had.

Maybe some more experienced folks can explain if there is any? In my case it all drills down to having single JDK distribution for each major JDK version (8, 11, 17, 21).

[roele]

I see. This might be indeed useful if you don't care about vendors and only need a JVM of a certain major version.

So you basically want a version file with value 20 which will match any installed 20.x JDK. This currently clashes with non-prefixed versions being a shorthand for openjdk-. Changing this behaviour will break backwards compatibility.

As i see it this would probably require a new scope as none of the existing scopes (e.g. prefix) fit that use-case. Something like regex:(\w+-)20(\..*)?