jdx
core java plugin - inconsistent version resolution
Describe the bug
Version resolution is inconsistent between JVM vendors. Root cause being that the versions aren't consistent between vendors.
To Reproduce
Make sure to run this with no local installs of java
> mise use java@17
...
mise ~/foo/.mise.toml tools: [email protected]
> java -version
openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment (build 17.0.2+8-86)
OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)
✅ You get the latest openjdk 17 release
> mise use java@sapmachine-17
...
mise ~/foo/.mise.toml tools: java@sapmachine-17
> java -version
openjdk version "17" 2021-09-14 LTS
OpenJDK Runtime Environment SapMachine (build 17+35-LTS-sapmachine)
OpenJDK 64-Bit Server VM SapMachine (build 17+35-LTS-sapmachine, mixed mode)
❌ You get the initial sapmachine 17 release, not the most recent which would be 17.0.10 at the time of writing
❯ mise ls-remote java@sapmachine-17
sapmachine-17
sapmachine-17.0.1
...
sapmachine-17.0.10
sapmachine-17.0.4-snapshot.0
sapmachine-17.0.7-snapshot.1
Expected behavior
Regardless of the vendor, if I use just the major version, I get the latest patch release for said version as per "fuzzy matching"
mise doctor output
`mise doctor`
version: 2024.4.0 macos-arm64 (2024-04-02)
activated: yes
shims_on_path: yes
build_info:
Target: aarch64-apple-darwin
Features: DEFAULT, NATIVE_TLS
Built: Tue, 2 Apr 2024 01:55:39 +0000
Rust Version: rustc 1.77.1 (7cf61ebde 2024-03-27) (Homebrew)
Profile: release
shell:
/bin/zsh
zsh 5.9 (x86_64-apple-darwin23.0)
dirs:
data: ~/.../.mise
config: ~/.../.mise
cache: ~/.../.mise
state: ~/.../.mise
shims: ~/.../.mise/shims
config_files:
~/.../.mise/config.toml
~/.../foo-mise-java/.mise.toml
plugins:
bun (core)
deno (core)
go (core)
gradle https://github.com/rfrancis/asdf-gradle.git#ffc271c
java (core)
maven https://github.com/halcyon/asdf-maven.git#83fb4db
node (core)
python (core)
ruby (core)
vault https://github.com/asdf-community/asdf-hashicorp.git#197e3ec
toolset:
java@sapmachine-17
[email protected]
[email protected]
env_vars:
MISE_DIR=/Users/.../.mise
MISE_CONFIG_DIR=/Users/.../.mise
MISE_CACHE_DIR=/Users/.../.mise
MISE_STATE_DIR=/Users/.../.mise
MISE_DATA_DIR=/Users/.../.mise
MISE_SHELL=zsh
settings:
activate_aggressive = false
all_compile = false
always_keep_download = false
always_keep_install = false
asdf_compat = false
cargo_binstall = true
color = true
disable_default_shorthands = false
disable_tools = []
experimental = false
go_default_packages_file = "~/.default-go-packages"
go_download_mirror = "https://dl.google.com/go"
go_repo = "https://github.com/golang/go"
go_set_gopath = false
go_set_goroot = true
go_skip_checksum = false
jobs = 4
legacy_version_file = true
legacy_version_file_disable_tools = []
node_compile = false
not_found_auto_install = true
paranoid = false
plugin_autoupdate_last_check_duration = "7d"
python_compile = false
python_default_packages_file = "/Users/I327130/.default-python-packages"
python_pyenv_repo = "https://github.com/pyenv/pyenv.git"
raw = false
trusted_config_paths = []
quiet = false
verbose = false
yes = false
ci = false
debug = false
trace = false
log_level = "info"
python_venv_auto_create = false
[status]
missing_tools = "if_other_versions_installed"
show_env = false
show_tools = false
1 problem found:
1. new mise version 2024.4.3 available, currently on 2024.4.0
Additional context
Honestly I'm not quite sure if this should be a bug or a feature.
Interestingly enough, the problem is already recognized, at least for openjdk where major versions are normalized already:
https://github.com/jdx/mise/blob/main/src/plugins/core/java.rs#L70-L71
otherwise mise use java@17 would behave the same (incorrect) way 😄
I was curious and ran a little check against all java versions listed by ls-remote.
Besides openjdk, affected vendors seem to be oracle, sapmachine and (probably) liberica
❯ mise ls-remote java | grep -E '.*-[0-9]+(\+[0-9]+)?$'
liberica-jre-javafx-18+37
liberica-jre-javafx-19+37
liberica-jre-javafx-20+37
liberica-jre-javafx-21+37
liberica-jre-javafx-22+37
liberica-jre-18+37
liberica-jre-19+37
liberica-jre-20+37
liberica-jre-21+37
liberica-jre-22+37
liberica-javafx-18+37
liberica-javafx-19+37
liberica-javafx-20+37
liberica-javafx-21+37
liberica-javafx-22+37
liberica-lite-18+37
liberica-lite-19+37
liberica-lite-20+37
liberica-lite-21+37
liberica-lite-22+37
liberica-18+37
liberica-19+37
liberica-20+37
liberica-21+37
liberica-22+37
openjdk-17
openjdk-18
openjdk-19
openjdk-20
openjdk-21
openjdk-22
openjdk-23-loom+2-48
oracle-17
oracle-18
oracle-19
oracle-20
oracle-21
oracle-graalvm-21
sapmachine-jre-17
sapmachine-jre-18
sapmachine-jre-19
sapmachine-jre-20
sapmachine-jre-21
sapmachine-jre-22
sapmachine-17
sapmachine-18
sapmachine-19
sapmachine-20
sapmachine-21
sapmachine-22
This looks inconsistent indeed, will need to dig into this since it works for some and not for others. In the meantime i would have suggested to use the workaround using a prefix: scope but it looks that this is also not working as expected with #1888.
Behaviour is consistent in the sense that it uses the "exact" match if found, otherwise falls back to newest available version matching the provided version. The @17 version is a shorthand for openjdk which behaves a bit differently as you have pointed out.
17 --> openjdk-17.0.2
openjdk-17 --> openjdk-17
sapmachine-17 --> sapmachine-17
liberica-17 --> liberica-17.0.10+13 (no liberica-17 version, so newest 17.x is installed)
oracle-17 --> oracle-17
IMO this behaviour is correct since you need a way to install version 17(.0.0) somehow. If you need the newest version it's best to use the prefix: scope.
to make it even more fun:
❯ mise use [email protected]
...
OpenJDK Runtime Environment SapMachine (build 17.0.11+9-LTS)
OpenJDK 64-Bit Server VM SapMachine (build 17.0.11+9-LTS, mixed mode, sharing)
mise [email protected] ✓ installed
mise ~/foo/.mise.toml tools: [email protected]
❯ mise use java@sapmachine-17
mise ~/foo/.mise.toml tools: [email protected]
I humbly suggest to nnormalilze all versions when ingesting data for https://rtx-java-metadata.jdx.dev
Interestingly this does not happen if sapmachine-17 is already installed.
❯ mise i java@sapmachine-17
❯ mise use [email protected]
...
OpenJDK Runtime Environment SapMachine (build 17.0.11+9-LTS)
OpenJDK 64-Bit Server VM SapMachine (build 17.0.11+9-LTS, mixed mode, sharing)
mise [email protected] ✓ installed
mise ~/foo/.mise.toml tools: [email protected]
❯ mise use java@sapmachine-17
mise ~/foo/.mise.toml tools: java@sapmachine-17
Clearly the fuzzy matching logic interferes in this case, returning a match where it should not.
How about this:
Instead of making the version resolution logic more complicated, normalize the input data.
If java versions where consistent (major.minor.patch) across all vemdors in rtx-java-metadata, all of this would go away and you could even drop the secret sauce to make java@21 work as expected.
Happy to help if that's the route you want to take.
@mpern Agree that this might be a better solution but i assume this will be quite some effort. I'm not familiar with the java-metadata repo in detail but historic metadata would need to be updated manually as it is not updated automatically (only new versions are added AFAIK).
@jdx What is your take on this? Can you think of any potential implications adding .0.0 for such versions?
Edit: Prepared 2 PRs in rtx-java-metadata https://github.com/jdx/rtx-java-metadata/pull/1 https://github.com/jdx/rtx-java-metadata/pull/2
I'll let you decide, I don't have a strong preference. I can't think of any problems with that.
Okey, i'm clearly in favour of having a consistent solution by normalizing the versions in rtx-java-metadata.
@mpern with PR https://github.com/jdx/rtx-java-metadata/pull/2 merged, this should be resolved now. After mise cache clear the command mise ls-remote java should show no more semantically incorrect versions.