Closed rocketraman closed 1 month ago
The shorthand (non-prefixed) version refers to openjdk which only receives updates for 6 months after GA. Java metadata is provided by https://github.com/jdx/rtx-java-metadata.
Also see:
Thank you for the quick response and clarification of the behavior. My follow up question would be: does it make sense for the raw numeric shortcuts to refer to the non-updated openjdk?
Or perhaps there should be a config mechanism to set the preferred vendor for the non-qualified values?
Also a related request would be: allow specifying the latest version of a specific vendor. For example:
java@corretto-17
would refer to the latest version of corretto JDK, just like 17
refers to the latest version of openjdk-17.
I can open separate issues for these things if that makes sense.
Also a related request would be: allow specifying the latest version of a specific vendor.
Ah, I see it already does this. It just doesn't list these options in ls-remote
. I'd love to see the output of ls-remote
look something like this:
temurin-21.0.0+35.0.LTS
temurin-21.0.1+12.0.LTS
temurin-21.0.2+13.0.LTS
temurin-21.0.3+9.0.LTS
temurin-21.0.4+7.0.LTS
temurin-21 -> temurin-21.0.4+7.0.LTS
I personally like the idea of having another vendor (than openjdk) for a shorthand. Not sure how feasible this will be though, will check it out if i find some time.
I don't think mise
should list non-existent artifacts. This is more of a versioning behaviour of mise
which is implicit.
that output would break scripts
I'm not really in favor of using a different vendor for the shorthand just because my understanding is that openjdk is generally considered the "standard" and the most popular. I think anything else as the default would be surprising even if we think it's something more users would prefer.
that said, I'd be open to making the default jdk a setting
that output would break scripts
How about gated behind a flag like --show-links
or something like that? It would increase discoverability greatly. For example, I had no idea I could use temurin-latest
and temurin-17
until I raised this issue and dug into things on my own.
they aren't links, it's just prefix matching
they aren't links, it's just prefix matching
Ah, ok. temurin-latest
isn't a prefix -- is "latest" a special case?
I agree that openjdk
should stay the default. Having a setting (e.g. java_shorthand_vendor
) might be something we can add relatively easily. But this is rather something that would need to be used cautiously as a project with a tool java = "23"
might install a different Java distribution for someone having this changed.
But this is rather something that would need to be used cautiously as a project with a tool
java = "23"
might install a different Java distribution for someone having this changed.
That is true. Maybe the setting should only apply to global installs, and not per-project installs. Per-project installs should use the same JDK consistently on different machines and users.
For some this behaviour could even be desired as #1674 shows. But such a setting (on project level) would also mess with the major/minor/patch symlinks that are created. So in the end i'm leaning towards keeping things as they are.
I actually don't see any use-case for globally using such a setting. Though I also see no reason to restrict it, @roele is right we wouldn't have support for doing one and not the other anyways. I can think of one for projects though.
I could see a maintainer just wanting to define a Java version without mandating a particular flavor.
Of course this is what mise.local.toml is for but maybe if a company has a lot of Java projects but loose restrictions on the flavor it might be handy.
Closing this issue in favor of better specified feature request https://github.com/jdx/mise/issues/2620.
Describe the bug Doing
mise ls-remote java
lists both vendor distributions as well as non-vendor distributions like "openjdk-*" as well as just the raw versions like "17" and "21".I don't know which distributions are actually provided by values like "openjdk-17", "openjdk-21", "17", and "21" (and possibly others) [1], but they are out of date.
[1] As an aside it would be helpful to show which entries were actually links to other entries in the output of ls-remote, like
ls -l
does.To Reproduce
Taking the most recent LTR release versions:
but seeing what is available from the various vendors we can see that 17.0.12 and 21.0.4 are available:
Expected behavior I would expect the non vendor specific entries to have a more recent version provided.
mise doctor
output