A way to specify `asdf shell java 11`

[dkowis]

For simplicity, it'd be nice to have that behavior similar to how jenv shell 11 would work. Just use the java 11 that you have available. If you've got more than one, it should probably fail.

It'd sure be nice to be able to use a .java-version with just 11 in it. As best as I can tell that won't work?

I've got java stuff that just needs to run on some java 1.8. And other things that just need some java 11. So it'd be nice if it could pick a tool that is compatible with java 1.8 or java 11, without having to be explicit about the precise versions of JVM installed.

~ > cd ~/apacheds/ApacheDirectoryStudio/
apacheds/ApacheDirectoryStudio > java -version
asdf: No preset version installed for command java
Please install the missing version by running one of the following:

asdf install java 1.8

or add one of the following in your .tool-versions file:

java adopt-openjdk-11.0.7+10
java adopt-openjdk-8u252-b09
apacheds/ApacheDirectoryStudio > cat .java-version
1.8

[joschi]

@dkowis Which of the supported OpenJDK distributions (AdoptOpenJDK, Amazon Corretto, Zulu Community) and in which variant (OpenJ9, large heap) would you expect to be used when using asdf install java 11?

[dkowis]

Without being opinionated, I wouldn't expect it to install one, as that's terribly ambiguous. But to take an opinionated software stance, I'd pick an AdoptOpenJDK 11, hotspot variant, if one wasn't specified. I think it's okay to be moderately opinionated for simplicity's sake during an install, as you can choose explicitly the other ones, if you want them :)

I was thinking about the version file being able to pick some java 11 after it's installed. jenv uses the most recently installed one to be "11" So if you installed AdoptOpenJDK 11.something and then Corretto 11.something. It would choose Corretto, since it was the most recently installed 11.something.

I'm open to other ideas, of course! I would just like the convenience of being able to specify a "java 11" in my java tool file, without having to be explicit, unless I wanted that specificity. Most often, I'll update patch levels of java and I don't think I should have to update all my .java-version files in all the repos to match.

I'm also open to more interesting version parsing logic (which might be hard!) things like 1.8-openj9, corretto-1.8, zulu-11. That way, if I installed a newer patchlevel version of any of those, it'd still do the right thing, but not pick a different vendor.

It would be a significantly more complex (and awesome!) version parsing logic though.

[augustobmoura]

You can symlink one specific version to the name 11, just run:

ln -s "$(asdf where java adopt-openjdk-11.0.7+10)" "$ASDF_DIR/installs/java/11"

and then:

asdf reshim java

You can replace adopt-openjdk-11.0.7+10 with the latest candidate that you consider the canon "11" Retrieving the last candidate for a given version automatically is way harder

[delgurth]

I think adding an alias can be done using: https://asdf-vm.com/#/plugins-create?id=extension-commands-for-asdf-cli

I'm currently thinking about adding ~2~1 custom command~s~:

• ~asdf java alias <version> <alias>~
  • ~To be able to link an already installed version to a custom alias in order to (partially) fix this issue~
• asdf java add <jdk>
  • Provide a way to add a local installed version, like https://github.com/jenv/jenv/blob/master/libexec/jenv-add. This would fix #95

~This will at least provide an easy way to add custom aliases. After that I guess adding something post-install for the first major version could be nice, as proposed by @dkowis.~

For adding aliases https://github.com/andrewthauer/asdf-alias sounds like the better option.

[augustobmoura]

@delgurth there's a plugin for that same functionality, take a look at https://github.com/andrewthauer/asdf-alias

[delgurth]

@augustobmoura thanks, guess we need to add a bin/help.links to link to this plugin as a useful companion plugin.

[delgurth]

@augustobmoura have you used this plugin successfully?

I first tried the regular version, first facepalm: install instructions are incorrect. But changing asdf-alias to just alias made it work. But now I'm getting: asdf alias: The plugin 'java' could not be found

So I tied the version of a guy who claims he fixed the plugin finding a few months ago

❯ asdf plugin remove alias
❯ asdf plugin add alias https://github.com/jtzero/asdf-alias.git
❯ asdf alias java 11.0 adoptopenjdk-11.0
asdf alias: The plugin 'java' could not be found

This doesn't look promising. Is it worth looking into or should I go back to my original plan?

[augustobmoura]

There's https://github.com/asdf-vm/asdf/issues/523 about aliases in asdf-core that should take a look, there are some insightful discussion about this problem. We had some aliases in other plugins but is still very premature, if anything I would start with the discussion in asdf-core. About the plugin, I did tested it a while ago, maybe something got borked in between

We could add the alias subcommand to asdf-java but the real question is if we should haha

By now the only way of aliasing is manually symlinking-reshimming, using a subcommand plugin or plain shell aliases is the user's choice

[bric3]

• Provide a way to add a local installed version, like https://github.com/jenv/jenv/blob/master/libexec/jenv-add. This would fix #95

Hi, just chiming in, currently I'm using specific JDK builds and I'm doing the following. This would be nice if the add a local version could be extended to adding a remote version too.

$ curl -sLO https://download.java.net/java/early_access/loom/4/openjdk-17-loom+4-174_osx-x64_bin.tar.gz
$ mkdir -p openjdk-17-loom+4-174; tar --strip-components=4 -C openjdk-17-loom+4-174/ -xf openjdk-17-loom+4-174_osx-x64_bin.tar.gz jdk-17.jdk/Contents/Home
$ asdf reshim java

$ curl -sLO https://download.java.net/java/early_access/lanai/3/openjdk-17-lanai+3-133_osx-x64_bin.tar.gz
$ mkdir -p openjdk-17-lanai+3-133; tar --strip-components=4 -C openjdk-17-lanai+3-133/ -xf openjdk-17-lanai+3-133_osx-x64_bin.tar.gz jdk-17.jdk/Contents/Home
$ asdf reshim java

[delgurth]

@augustobmoura found what was wrong with asdf alias in my case. Created a pull request for that. It didn't work for people who did not have the ASDF_DATA_DIR set, and the workaround from jtzero didn't work for me because my ASDF_DATA_DIR was not within my ASDF_DIR. Hopefully this pull request will be accepted so that we can add advice in here to use asdf-alias as the preferred method to custom name versions.

@bric3 not sure how easy this would be, it would only work if those remote versions contained the same directory structure/setup. The loom and lanai builds do seem to be "according to standard", but your example shows that you are doing something different depending on the external version you are downloading. That's hard to do in a standard plugin function.

In this case using a different approach (the default approach used in this plugin) would work for both in the same way though. So I think this should be doable. Not making any promises though.

[bric3]

@delgurth Here the only difference is the name of the JDK in asdf. Here the tedious and error-prone part is the tar command.

I would have preferred to identify the version in a automated way (java --version, $JAVA_HOME/release file) but this turned to be unreliable to install these variants.

[trydofor]

what about this way instead of alias

asdf list all java 'temurin-21'

#>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

asdf local java temurin-21

## should install the latest `temurin-21.0.3+9.0.LTS`