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 openjdk@1.11.0-2).

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 adopt@1.11.0-11).

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.