Basic aliases for installation à la NVM

[benjamin-rood]

I think there is a missing ease-of-use functionality that Jabba needs.

Since this tool is modeled on NVM, nvm has built-in defaults and aliases when wanting to install a version of Node.

Example:
  nvm install 8.0.0                     Install a specific version number
  nvm use 8.0                           Use the latest available 8.0.x release
  nvm run 6.10.3 app.js                 Run app.js using node 6.10.3
  nvm exec 4.8.3 node app.js            Run `node app.js` with the PATH pointing to node 4.8.3
  nvm alias default 8.1.0               Set default node version on a shell
  nvm alias default node                Always default to the latest available node version on a shell

Compare the output of nvm ls-remote and jabba ls-remote. Both output a very long list of versions - the significant difference is the use of aliases attached to versions with nvm.

If I run nvm install stable it will install the latest stable release of node. If I run nvm install lts/erbium it will install the latest version of erbium a.k.a. node v12.

I think underneath what is being asked here is the equivalent sort of functionality for jabba.

So, if I run jabba install stable the expected equivalent behavior would be to install the latest LTS version of openjdk (which, as of writing this, would be [email protected]).

Just make the assumption that people want OpenJDK by default. That is what most people do want, after all: A version of java that is going to be the most compatible and widely-used.

If I run jabba install openjdk/16 or openjdk@16 it should install the latest stable version of OpenJDK for Java 16. The JDK packages may be indexed/numbered as 1.x.x but the public-facing branding is on the whole number and that has been the case for years now. Similarly, if I run jabba install adopt@11 it should install the latest stable version of the Adopt JDK for Java 11 (which is currently [email protected]).

Other versions like GraalVM are more tricky, and implementing aliases for that would up for debate, but the above functionality is the reasonable expected equivalent behavior, and overall just a reasonable functionality to implement to make things easier. I personally couldn't care less about the differences between 1.11.0-4.11.1 of amazon-corretto and 1.11.0-11.9.1 of the same JDK unless I get an error message, and I am certain that sentiment is shared by 99.9% of developers. By default, I would just want the latest version of the JDK that matches the Java release. It's perfectly sensible to assume that the latest version has the latest bugfixes and compatibility.

For people that want specific versions, then they use the current syntax. All that needs to be done is add additional basic aliases to the JDK version names/labels.

[benjamin-rood]

(note that I originally wrote this up as a comment on #748 , but once I was done I realised it was complete enough to be its own issue)

I write Go code every other day for my main gig, and I have been coding with it on and off for ~5 years now. I'm happy to put in the work to get this feature off the ground myself if people approve the spec.

[willcohen]

Sounds good to me! Let's shoot for an "0.11.3" that just wraps up all the random PRs that have been merged the last couple of months and any lingering features that we want to get put in in the next few weeks, and then we can work on a longer project roadmap from there.

[willcohen]

Now, I will say that I'm reasonably convinced that adopt may not be the right move for lts. We definitely shouldn't use [email protected], since Oracle's JDK 11 hasn't gotten bugfixes since 12 was released. I've seen good arguments that adopt may not be as surefire a bet as is sometimes let on (https://www.reddit.com/r/java/comments/i5zyyk/wtf_does_lts_even_mean_ffs/g0so60h?utm_source=share&utm_medium=web2x&context=3). My instinct is to go with the latest corretto or zulu for "stable," since it'll have backported fixes.

[willcohen]

Turns out my previous comment may be a little out of date. In light of shyiko/jabba-autodiscovery#15 (which very much still needs to happen), along with fixing the busted autodiscovery for zulu there, it seems like the newly rebranded Adoptium builds WILL be TCK-compliant, which would mean that they'll be a reasonable default, though it does seem like it'll be a few days still before they get a full release out for all platforms (https://projects.eclipse.org/projects/adoptium.temurin-compliance). All else being equal I like the idea of having the default be a multi-stakeholder and foundation-led build versus one tied to a single entity.