jdx / mise

dev tools, env vars, task runner
https://mise.jdx.dev
MIT License
9.98k stars 288 forks source link

Mise non-vendored openjdk and raw versions are not up-to-date #2618

Closed rocketraman closed 1 month ago

rocketraman commented 1 month ago

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:

# mise ls-remote java | grep "^17"
mise pruning old cache files, this behavior can be modified with the MISE_CACHE_PRUNE_AGE setting
17.0.0
17.0.1
17.0.2

# mise ls-remote java | grep "^21"
21.0.0
21.0.1
21.0.2

but seeing what is available from the various vendors we can see that 17.0.12 and 21.0.4 are available:

# mise ls-remote java | grep adoptopenjdk-17
adoptopenjdk-17.0.0+35
adoptopenjdk-17.0.1+12
adoptopenjdk-17.0.2+8
adoptopenjdk-17.0.3+7
adoptopenjdk-17.0.4+101
adoptopenjdk-17.0.4+8
adoptopenjdk-17.0.5+8
adoptopenjdk-17.0.6+10
adoptopenjdk-17.0.7+7
adoptopenjdk-17.0.8+101
adoptopenjdk-17.0.8+7
adoptopenjdk-17.0.9+9
adoptopenjdk-17.0.10+7
adoptopenjdk-17.0.11+9
adoptopenjdk-17.0.12+7

# mise ls-remote java | grep adoptopenjdk-21
adoptopenjdk-21.0.0+35.0.LTS
adoptopenjdk-21.0.1+12.0.LTS
adoptopenjdk-21.0.2+13.0.LTS
adoptopenjdk-21.0.3+9.0.LTS
adoptopenjdk-21.0.4+7.0.LTS

Expected behavior I would expect the non vendor specific entries to have a more recent version provided.

mise doctor output

version: 2024.9.6 linux-x64 (1c0bc95 2024-09-18)
activated: yes
shims_on_path: no

build_info: 
  Target: x86_64-unknown-linux-gnu
  Features: DEFAULT, NATIVE_TLS, OPENSSL
  Built: Wed, 18 Sep 2024 21:37:42 +0000
  Rust Version: rustc 1.81.0 (eeb90cda1 2024-09-04)
  Profile: release

shell: 
  /usr/bin/fish
  fish, version 3.7.0

dirs: 
  data: ~/.local/share/mise
  config: ~/.config/mise
  cache: ~/.cache/mise
  state: ~/.local/state/mise
  shims: ~/.local/share/mise/shims

config_files: 
  ~/.config/mise/config.toml
  ~/.mise.toml
  ~/source/devhaus/mobile-sdk/.mise.toml

backends: 
  cargo
  core
  go
  npm
  pipx
  spm
  ubi
  vfox

plugins: 

toolset: 
  java@17.0.2   
  node@20.17.0  

env_vars: 
  MISE_SHELL=fish

settings: 
  activate_aggressive = false
  all_compile = false
  always_keep_download = false
  always_keep_install = false
  asdf = true
  asdf_compat = false
  cache_prune_age = "30d"
  cargo_binstall = true
  color = true
  disable_default_shorthands = false
  disable_hints = []
  disable_tools = []
  experimental = true
  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
  http_timeout = 30
  jobs = 4
  legacy_version_file = true
  legacy_version_file_disable_tools = []
  libgit2 = true
  node_compile = false
  not_found_auto_install = true
  paranoid = false
  pipx_uvx = false
  plugin_autoupdate_last_check_duration = "7d"
  python_default_packages_file = "~/.default-python-packages"
  python_pyenv_repo = "https://github.com/pyenv/pyenv.git"
  raw = false
  trusted_config_paths = []
  quiet = false
  use_versions_host = true
  verbose = false
  vfox = false
  yes = false
  ci = false
  debug = false
  trace = false
  log_level = "info"
  python_venv_auto_create = false

  [ruby]
  default_packages_file = "~/.default-gems"
  ruby_build_repo = "https://github.com/rbenv/ruby-build.git"
  ruby_install = false
  ruby_install_repo = "https://github.com/postmodern/ruby-install.git"

  [status]
  missing_tools = "if_other_versions_installed"
  show_env = false
  show_tools = false

No warnings found
No problems found
roele commented 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:

rocketraman commented 1 month ago

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?

rocketraman commented 1 month ago

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.

rocketraman commented 1 month ago

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
roele commented 1 month ago

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.

jdx commented 1 month ago

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.

jdx commented 1 month ago

that said, I'd be open to making the default jdk a setting

rocketraman commented 1 month ago

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.

jdx commented 1 month ago

they aren't links, it's just prefix matching

rocketraman commented 1 month ago

they aren't links, it's just prefix matching

Ah, ok. temurin-latest isn't a prefix -- is "latest" a special case?

roele commented 1 month ago

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.

rocketraman commented 1 month ago

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.

roele commented 1 month ago

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.

jdx commented 1 month ago

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.

rocketraman commented 1 month ago

Closing this issue in favor of better specified feature request https://github.com/jdx/mise/issues/2620.