This is a feature that I miss from jEnv. I can't remember all the specific names/versions of the things I have installed, particularly JDKs. But I know I want to use "java 8" (whichever specific version is installed).

Introduce aliases tracking latest builds for major versions

Hey @marc0der, are there any plans to add support for this? The proposal has accumulated quite a few of 👍 from the community. Thanks!

@vpavic I would love to develop this feature, although I realise that it will have huge impact on both the backend and cli components of the project. Since sdkman is an open source project developed in my spare time, I currently don't have enough time available to pull this off alone. The options would be:

• get some crowd funding off the ground so I can take off some time to develop it
• we assemble a team of contributors and build the feature together

I am creating and using a script like this (sdkjava.sh):

# check .bashrc
export SDKMAN_DIR="/Users/user/.sdkman"
[[ -s "/Users/user/.sdkman/bin/sdkman-init.sh" ]] && source "/Users/user/.sdkman/bin/sdkman-init.sh"

sdk offline disable > /dev/null

MAJOR_VERSION="$1"
export JDK_VERSION=`sdk list java | grep -E "installed|local only" | awk '{print $NF}' | grep "^$MAJOR_VERSION" | sort -rn | head -1`

if [[ -z "$JDK_VERSION" ]]; then
  echo "not find jdk major version: $MAJOR_VERSION"
  exit;
fi

echo -e "find jdk version: \033[1m${JDK_VERSION}"
sdk default java "$JDK_VERSION"

sdk offline enable > /dev/null

using

$ ./sdkjava.sh 8
-e find jdk version: 8.0.222.hs-adpt

-e Using java version 8.0.222.hs-adpt in this shell.

But I don't know how to clear the following two lines and write a script. (This code is included in .bashrc)

export SDKMAN_DIR="/Users/user/.sdkman"
[[ -s "/Users/user/.sdkman/bin/sdkman-init.sh" ]] && source "/Users/user/.sdkman/bin/sdkman-init.sh"

Hi, I've just created a simple script for switching between major Java versions: https://github.com/ldziedziul/j

This would be great, esp. for setting up SDKs in IDEA (or other IDEs); reconfiguring after every bugfix release is a hassle.

As long as candidates use regular versions, all is good.

Java, however, breaks all the assumptions.

• What if a user installs multiple SDKs at the same major/minor/patch version?
• How to disentangle GraalVM from the bunch?

Allow me to propose the following use cases that I proposed on https://sdkman.slack.com/archives/CJK9DMV6V/p1635547088005000 :

"SDKman: if there is already a Java 11 version installed, use whichever one is first on the list of installed Java 11 versions. If none is loaded, then tell the user that they need to install a Java 11 version of some sort through SDKman"
-- or --
"SDKman: here are the versions of Java that are considered acceptable for use. The first one you find, use that one. If none is loaded, then tell the user that they need to install one of the following list:
11.0.11.j9-adpt
11.0.11.hs-adpt
11.0.13.8.1-amzn
11.0.12.7.2-amzn
11.0.13.fx-librca"
(note1: I left off a bunch of other ones. Those would not be considered as acceptable to the project.)
(note2: In theory if the Java code could be compiled using either Java 8 or 11, I could add a few Java 8 versions as well. Again, in theory...)

The major use case of this for me would be to be able to have portable .sdkmanrc that could be committed to a project's repository and that worked across different users with different jdks installed.

I can commit a file with java=17.0.2-tem but then that will fail for a user who only has 17.0.1-tem or a different java 17 distro.

Ideally we could just put
java=17 and SDK man could automatically pick whatever valid version of Java 17 was available within each users environment.

@marc0der if you point me in the right direction, this is a big enough pain point for me, that I might take some time to do this.

A potential poor-man's solution to this is to "install a local version" that's at the same path of an already-installed java: sdk install 11 <candidate path>

jakebman@host:~/.sdkman/candidates/java$ sdk install java 11 11.0.15-zulu/
Linking java 11 to /home/jakebman/.sdkman/candidates/java/11.0.15-zulu/
Done installing!

jakebman@host:~/.sdkman/candidates/java$ sdk use java 11

Using java version 11 in this shell.
jakebman@host:~/.sdkman/candidates/java$ sdk list java | { head -n5; grep " 11 "; }
================================================================================
Available Java Versions for Linux 64bit
================================================================================
 Vendor        | Use | Version      | Dist    | Status     | Identifier
--------------------------------------------------------------------------------
 Unclassified  | >>> | 11           | none    | local only | 11

It's 'shallow' - sdk uninstall java 11 and others only operate on this "local" installation, and not on 11.0.15-zulu.
I'm dubious that this is the right-and-proper implementation for this feature request, but it's at least a way to eat your cake before you bake it.

A potential poor-man's solution to this is to "install a local version" that's at the same path of an already-installed java: sdk install 11 <candidate path>

jakebman@host:~/.sdkman/candidates/java$ sdk install java 11 11.0.15-zulu/
Linking java 11 to /home/jakebman/.sdkman/candidates/java/11.0.15-zulu/
Done installing!

I like the approach as a workaround, but enhanced the command to:

sdk install java 11 `sdk home java 11.0.15-zulu`

This way I do not have to know where SDKman installs its versions to and I can easily upgrade my version alias by running:

sdk install java <new version>
sdk uninstall java 11
sdk install java 11 `sdk home java <new version>`

Just a little improvement, though, but its enough to create a shell function that takes two parameters (majorVersion, fullVersion):

function installNewJavaVersionViaSDKman {
	sdk install java $2
	sdk uninstall java $1
	sdk install java $1 `sdk home java $2`
}

At least, this saves me a bit of time in my weekly update workflow.

This would be a great feature. I'd also suggest some (optional) way to scope by 'type'. So basically, for most cases what's already covered here install/use/etc 'java 11'. But something like '.. java 11-amzn', might be useful as well. In most cases you don't really care, but i can see it mainly being useful if you want say GraalVM in certain situations.

Also, with this in place, would be nice to have a way to scope updates. where one could do something like sdk update java 11-amzn and that would pull the most recent point release and set it to the alias.