We Keep Coding

How to use different java version by alias?

I have some tools that can only be run by java 8. So i downloaded java 8, but now i have two versions of java installed at the same time (os : Ubuntu):
java-1.11.0-openjdk-amd64 1101 /usr/lib/jvm/java-1.11.0-openjdk-amd64
java-1.8.0-openjdk-amd64 1081 /usr/lib/jvm/java-1.8.0-openjdk-amd64
My question is: is it possible to call these both versions by different aliases? For example i type:
"java" to call java 11 (the default) and
"java8" to call java 8

You could do it in a couple of ways. The easiest way would be to put the following 2 lines in your profile initialization file:
alias java='/usr/lib/jvm/java-1.11.0-openjdk-amd64/bin/java'
alias java8='/usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java'
Other ways are depending on whether you are the admin of the machine or not. You can create soft links like this:
/usr/bin/java -> /usr/lib/jvm/java-1.11.0-openjdk-amd64
(Not recommended since certain tools in your system may depend on /usr/bin/java).
Update: Try to use sdkman if you can. Makes the job of installing java versions and setting up JAVA_HOME env variable simple.

You can do this as well for JAVA_HOME:
alias java8="export JAVA_HOME=`/usr/libexec/java_home -v 1.8`"
alias java11="export JAVA_HOME=`/usr/libexec/java_home -v 11`"
Updated:
To run java directly use:
$ alias java8="`/usr/libexec/java_home -v 1.8`/bin/java"
$ alias java11="`/usr/libexec/java_home -v 11`/bin/java"
$ java8 -version
java version "1.8.0_281"
Java(TM) SE Runtime Environment (build 1.8.0_281-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.281-b09, mixed mode)
$ java11 -version
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
You can hardcode your path as well.

I have some tools that can only be run by java 8. So I downloaded java 8, but now I have two versions of java installed at the same time (os : Ubuntu).
You could do this using aliases (see other answers) but this has the problem that only a shell will respect an alias ... and then only if it has the alias defined or loaded by the shell:
Aliases are not inherited via the environment.
Whether a tool's launch script will see the aliases will typically depend on whether you put the alias definitions into the correct shell init file.
It is also possible that an application's launch script will assume that java8 or java11 is a genuine (absolute or relative) pathname, and try to resolve it via the file system.
In short, there is a good chance that using an alias won't work in your use-case.
So a better idea is to arrange that the appropriate Java is on the Command Search Path. You could do this a number of different ways:
You could use the Ubuntu "alternatives" system to globally switch between Java 8 and Java 11.
You could update the PATH variable so that (for example) the Java 11 executables come before the Java 8 executables. This could be done in shell init files (per user or globally), in the application launch scripts ... or by hand.
You could even replace "/usr/bin/java" or whatever with a direct symlink to the version you want to use. (This is crude, and I wouldn't recommend it.) Note that the Java command entries in "/usr/bin" are probably already symlinks.)

Confusion about Java Versions

So I'm trying to get the latest version of Java. When I run:
java -version
I get:
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
When I run:
javac -version
I get:
javac 1.6.0_65
Now I've just downloaded and installed JDK 8. When I go into System Preferences --> Java --> Update, I see:
Your system has the recommended vesion of Java.
Java 8 Update 05.
I guess I have a few questions:
1) Don't I want the JDK and my version of Java to match up?
2) Why does my Java Control Panel claim I have Java 8, but my work in the terminal (when checking my Java version) says otherwise?
Thanks for the help,
Mariogs

The probably "simple" answer is you have two versions of java installed. On the command line you currently use 1.6. Thus the old one is active. In system preferences you see the version of java 8.
Windows:
You can change the version of the command line to java 8. Set PATH environment variable and JAVA_HOME or via windows preferences. I recommend the first one.
Mac: /usr/libexec/java_home is the starting point for switching java versions on the command line. Check out this post to understand how to handle different java versions on the Mac. IMHO this answer is a good solution.

The Java Platform offers both the JRE and the JDK in order for users to run Java programs. The JRE stands for the Java Runtime Environment, and the JDK stands for the Java Development Kit.
The JDK is meant for Java developers - that is, those who build applications/write programs in Java. It contains tools that are needed for Java coding, including -javac to compile programs.
The JRE is meant for regular users - those who only need to run Java programs on their computer and are not interested in development.
The reason for the discrepancy in your case is because you're looking at the JRE and JDK and trying to compare the two. The current JDK that you have is Java 8, whereas the current JRE that you have is 1.6.0_65. It is problematic that your JRE version does not match your JDK version, but without your PATH variable or other information about your install, we can't help you fix your installation.

1) Yes, if you use the JDK at all, you want the JRE (runtime environment) to come from the JDK (development environment) (a JDK necessarily includes a JRE).
2) Likely your path variable is set so that you invoke Java from your Java 6 installation; you need to find the equivalent for your Java 8 installation and set the path for that. Without information about your operating system, we can't help you do that.

We should know the reason for this
Our OS comes with a predefined (built-in)set of tools and utilities. When we try to execute the command e.g. cls in the Windows command line then it is already present in system path variable and os will refer the corresponding binary of cls to execute the command.
However, when we install any third party tool/software then path variable is not updated accordingly.
When we install different versions of java on your system then installations go to different directories. E.g. JDK installation directory for Windows will be
C:\Program Files\Java\jdk1.8.0_161
Similarly, JRE installation directory for Windows will be JDK installation directory for Windows will be
C:\Program Files\Java\jre1.8.0_161
We need to update the path variable of OS to point to the appropriate directory. If we set the path of JDK then it will execute a binary from JDK bin directory.
Solution
we need to update JDK or JRE version specific directory location into PATH Environment variable.

Let me see if I can clear it up for you.
1)Yes, arguably you nearly want this to be true.
2)It could be few things, but most likely that a previous instillation was not properly removed. So one gets called instead of the other.

I had Open JDK 1.7 on CentOS; I installed Oracle's Java rpm; Oracle Java doesn't seem to exist

I started off with CentOS and OpenJDK 1.7
# java -version
java version "1.7.0_25"
OpenJDK Runtime Environment (rhel-2.3.10.4.el6_4-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
In order to run a specific application, I want to use Oracle's Java 1.6, provided from an RPM.
I copied the Oracle binary to a specific new directory:
# pwd
/oracleJava/jdk-6u45-linux-x64-rpm
I extracted the binary and it gave me the following files:
# ls
jdk-6u45-linux-amd64.rpm
sun-javadb-core-10.6.2-1.1.i386.rpm sun-javadb-javadoc-10.6.2-1.1.i386.rpm
sun-javadb-client-10.6.2-1.1.i386.rpm sun-javadb-demo-10.6.2-1.1.i386.rpm
sun-javadb-common-10.6.2-1.1.i386.rpm sun-javadb-docs-10.6.2-1.1.i386.rpm
I installed the RPM and the rpm utility believes that it installed properly:
rpm -q jdk
jdk-1.6.0_45-fcs.x86_64
# rpm -Uvh ./*.rpm
Preparing... ########################################### [100%]
package jdk-2000:1.6.0_45-fcs.x86_64 is already installed
# rpm -Uvh sun-javadb-*.rpm
[I omit the feedback because it generates a formatting error]
#
However, the Java version just shows 1.7
# java -version
java version "1.7.0_25"
OpenJDK Runtime Environment (rhel-2.3.10.4.el6_4-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
In other words, I was expecting the Oracle files to give me some new /java directory somewhere, with a new java executable that would return a different answer for "java -version"
I need that new directory so that I can set JAVA_HOME and use the 1.6 version of Java.
Helpful suggestions would be greatly appreciated. Thanks in advance.

The Oracle JDK RPMs are horrible.
They do not register with the alternatives system.
They do not Provide (in RPM terms) "java"
They have messed up their RPM 'version string' and rely on Epoch (...)
All versions of the JDK (i.e. 1.6 vs 1.7) have the same Epoch
In order to quickly remedy your problem you can run the following:
/usr/sbin/alternatives --install /usr/bin/java java /usr/java/default/bin/java 20000
It will register and prefer the Oracle java installation as an alternative. OpenJDK has weight 16000; here we register with 20000. Once you've run this command you can switch between java versions by using the (already mentioned) alternatives --config java command.
As for a less quick fix you can use my virtual java package. It's quite possibly not perfect (I'm open for improvements ;) ), but it Provides java (making my apache-tomcat package happy) and registers with the alternatives system. This virtual package simply depends on jdk...you can find it here: https://github.com/keystep/virtual-java-rpm

Run the following command to see if your JVM is getting listed.
sudo update-alternatives --config java
If your JVM gets listed select it.

The problem is that Oracle's RPMs are (wilfully IMO!) ignorant of the "alternatives" system.
Instead, they install stuff in a non-standard place (/usr/java) and then expect the user / system administrator to mess with the PATH variable ... by hand.
It is a nuisance!
So what has probably happened in your case is that your JDK / JRE has been installed in a subdirectory of /usr/java ... but since you haven't added the relevant bin subdirectory to the front of your PATH you are still picking up the OpenJDK tools via the java command name.
You can fix this after the fact by using "alternatives" to configure and then select the Oracle commands. But it is messy, especially if you want the JDK tools as well. (There are a lot of them!)

Please check that whether your JAVA_HOME points to JDK 6 using echo $JAVA_HOME. In order change your JAVA_VERSION to Java 6, you need to point to the Java development KIT 6. You also need to add the bin directory to the $PATH variable. Please ensure that JDK6 bin directory comes in the $PATH prior to other JDK bin,if any. You can check the version of your Java in the environment by command java -version.The other answer by learningloop is very perfect to switch between different Java configurations

Try to the following method
delete OpenJDK folder from
/usr/lib/jvm
I had same problem and got solution through this method

How can I change Mac OS's default Java VM returned from /usr/libexec/java_home

(Wasn't sure if this should go on SU... migration is certainly an option, but more programmers read questions here, so here goes).
I am running Mac OS X 10.8.4, and I have Apple's JDK 1.6.0_51 installed as well as Oracle's JDK 1.7.0_25. I recently installed Oracle's 1.8 preview JDK for some pre-release software that requires it. Now, when I run /usr/libexec/java_home, I get this:
$ /usr/libexec/java_home -V
Matching Java Virtual Machines (4):
1.8.0, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
1.7.0_25, x86_64: "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home
1.6.0_51-b11-457, x86_64: "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
1.6.0_51-b11-457, i386: "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Great.
However, running:
$ java -version
Returns:
java version "1.8.0-ea"
That means that the default version of Java is currently the pre-release version, which breaks some "normal" packages (in my case, VisualVM).
I can't set JAVA_HOME because launching applications ignores environment variables, even when launching from the command line (e.g. $ open /Applications/VisualVM.app).
So, is there a file I can edit where I can set my JVM ordering preferences globally?
(Please don't tell me to launch the Java Preferences Panel because that simply does not work: it does not contain anything useful and only lists one of the 4 JVMs that I have installed.)
Update:
Oracle JVMs live in /Library/Java/JavaVirtualMachines. Re-naming the JDK 1.8 directory to jdk1.8.0.jvm.xyz does not change anything: java_home still finds it in the right place, and running /usr/bin/java still executes the 1.8 JVM. This is not an issue with synlinks, etc.
Answers to Similar Questions
While this answer offers what amounts to a hack that will remove versions of Java from being picked up by java_home, it still does not answer this question of how java_home chooses its default and whether or not users can non-destructively set it.

I think JAVA_HOME is the best you can do. The command-line tools like java and javac will respect that environment variable, you can use /usr/libexec/java_home -v '1.7*' to give you a suitable value to put into JAVA_HOME in order to make command line tools use Java 7.
export JAVA_HOME="`/usr/libexec/java_home -v '1.7*'`"
But standard double-clickable application bundles don't use JDKs installed under /Library/Java at all. Old-style .app bundles using Apple's JavaApplicationStub will use Apple Java 6 from /System/Library/Frameworks, and new-style ones built with AppBundler without a bundled JRE will use the "public" JRE in /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home - that's hard-coded in the stub code and can't be changed, and you can't have two different public JREs installed at the same time.
Edit: I've had a look at VisualVM specifically, assuming you're using the "application bundle" version from the download page, and this particular app is not an AppBundler application, instead its main executable is a shell script that calls a number of other shell scripts and reads various configuration files. It defaults to picking the newest JDK from /Library/Java as long as that is 7u10 or later, or uses Java 6 if your Java 7 installation is update 9 or earlier. But unravelling the logic in the shell scripts it looks to me like you can specify a particular JDK using a configuration file.
Create a text file ~/Library/Application Support/VisualVM/1.3.6/etc/visualvm.conf (replace 1.3.6 with whatever version of VisualVM you're using) containing the line
visualvm_jdkhome="`/usr/libexec/java_home -v '1.7*'`"
and this will force it to choose Java 7 instead of 8.

I've been there too and searched everywhere how /usr/libexec/java_home works but I couldn't find any information on how it determines the available Java Virtual Machines it lists.
I've experimented a bit and I think it simply executes a ls /Library/Java/JavaVirtualMachines and then inspects the ./<version>/Contents/Info.plist of all runtimes it finds there.
It then sorts them descending by the key JVMVersion contained in the Info.plist and by default it uses the first entry as its default JVM.
I think the only thing we might do is to change the plist: sudo vi /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plist and then modify the JVMVersion from 1.8.0 to something else that makes it sort it to the bottom instead of the top, like !1.8.0.
Something like:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
...
<dict>
...
<key>JVMVersion</key>
<string>!1.8.0</string> <!-- changed from '1.8.0' to '!1.8.0' -->`
and then it magically disappears from the top of the list:
/usr/libexec/java_home -verbose
Matching Java Virtual Machines (3):
1.7.0_45, x86_64: "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home
1.7.0_09, x86_64: "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home
!1.8.0, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
Now you will need to logout/login and then:
java -version
java version "1.7.0_45"
:-)
Of course I have no idea if something else breaks now or if the 1.8.0-ea version of java still works correctly.
You probably should not do any of this but instead simply deinstall 1.8.0.
However so far this has worked for me.

I actually looked at this a little in the disassembler, since source isn't available.
/usr/bin/java and /usr/libexec/java_home both make use of JavaLaunching.framework. The JAVA_HOME environment variable is indeed checked first by /usr/bin/java and friends (but not /usr/libexec/java_home.) The framework uses the JAVA_VERSION and JAVA_ARCH envirionment variables to filter the available JVMs. So, by default:
$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
11.0.5, x86_64: "Amazon Corretto 11" /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
1.8.0_232, x86_64: "Amazon Corretto 8" /Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
But setting, say, JAVA_VERSION can override the default:
$ JAVA_VERSION=1.8 /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home
You can also set JAVA_LAUNCHER_VERBOSE=1 to see some additional debug logging as far as search paths, found JVMs, etc., with both /usr/bin/java and /usr/libexec/java_home.
In the past, JavaLaunching.framework actually used the preferences system (under the com.apple.java.JavaPreferences domain) to set the preferred JVM order, allowing the default JVM to be set with PlistBuddy - but as best as I can tell, that code has been removed in recent versions of macOS. Environment variables seem to be the only way (aside from editing the Info.plist in the JDK bundles themselves.)
Setting default environment variables can of course be done through your .profile or via launchd, if you need them be set at a session level.

It's actually pretty easy.
Let's say we have this in our JavaVirtualMachines folder:
jdk1.7.0_51.jdk
jdk1.8.0.jdk
Imagine that 1.8 is our default, then we just add a new folder (for example 'old') and move the default jdk folder to that new folder.
Do java -version again et voila, 1.7!

I tested "jenv" and other things like setting "JAVA_HOME" without success.
Now I ended up with following solution:
function setJava {
export JAVA_HOME="$(/usr/libexec/java_home -v $1)"
launchctl setenv JAVA_HOME $JAVA_HOME
sudo ln -nsf "$(dirname ${JAVA_HOME})/MacOS" /Library/Java/MacOS
java -version
}
(added to ~/.bashrc or ~/.bash.profile or ~/.zshrc)
And calling like that:
setJava 1.8
java_home will handle the wrong input. So you can't do something wrong.
Maven and other stuff will pick up the right version now.

It's pretty simple, if you don't mind rolling up your sleeves... /Library/Java/Home is the default for JAVA_HOME, and it's just a link that points to one of:
/System/Library/Java/JavaVirtualMachines/1.?.?.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/jdk1.?.?_??.jdk/Contents/Home
So I wanted to change my default JVM/JDK version without changing the contents of JAVA_HOME... /Library/Java/Home is the standard location for the current JVM/JDK and that's what I wanted to preserve... it seems to me to be the easiest way to change things with the least side effects.
It's actually really simple. In order to change which version of java you see with java -version, all you have to do is some version of this:
cd /Library/Java
sudo rm Home
sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home ./Home
I haven't taken the time but a very simple shell script that makes use of /usr/libexec/java_home and ln to repoint the above symlink should be stupid easy to create...
Once you've changed where /Library/Java/Home is pointed... you get the correct result:
cerebro:~ magneto$ java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM)
64-Bit Server VM (build 25.60-b23, mixed mode)

Oracle's uninstallation instructions for Java 7 worked for me.
Excerpt:
Uninstalling the JDK
To uninstall the JDK, you must have Administrator privileges and execute the remove command either as root or by using the sudo(8) tool.
Navigate to /Library/Java/JavaVirtualMachines and remove the directory whose name matches the following format:*
/Library/Java/JavaVirtualMachines/jdk<major>.<minor>.<macro[_update]>.jdk
For example, to uninstall 7u6:
% rm -rf jdk1.7.0_06.jdk

A bit late but as this is an ongoing issue with Mac OSX...
The simplest solution I found was to simply remove the OpenJDK stuff that Apple installs. Every time an update of Mac OSX arrives it gets installed and you'll need to remove it again.
This works really well if you develop apps for Google App Engine on your mac using Java. The OpenJDK does not work well and the Java version that comes with the Mac OSX Yosemite upgrade will make the Eclipse Plug-in for App Engine crash on every deployment with the helpful error: "Read timed out".

Edit: this information is for visualvm specifically, not for any other java app
As mentioned by others, you need to modify the visualvm.conf
For the latest version of JvisualVM 1.3.6 on Mac, the install directories have changed.
It is currently in
/Applications/VisualVM.app/Contents/Resources/visualvm/etc/visualvm.conf.
However this may depend on where you have installed VisualVM. The easiest way to find where your VisualVM is to start it, and then look at the process using:
ps -ef | grep VisualVM
You will see something like:
... -Dnetbeans.dirs=/Applications/VisualVM.app/Contents/Resources/visualvm/visualvm...
You want to take the netbeans.dir property and look up a directory and you will find the etc folder.
Uncomment this line in the visualvm.conf and change the path to the jdk
visualvm_jdkhome="/path/to/jdk"
Additionally, if you are having slowness with your visualvm and you have a lot of memory, I would suggest greatly increasing the amount of memory available and running it in server mode:
visualvm_default_options="-J-XX:MaxPermSize=96m -J-Xmx2048m -J-Xms2048m -J-server -J-XX:+UseCompressedOops -J-XX:+UseConcMarkSweepGC -J-XX:+UseParNewGC -J-XX:NewRatio=2 -J-Dnetbeans.accept_license_class=com.sun.tools.visualvm.modules.startup.AcceptLicense -J-Dsun.jvmstat.perdata.syncWaitMs=10000 -J-Dsun.java2d.noddraw=true -J-Dsun.java2d.d3d=false"

Simplify the need :-)
Steps to changes --
Find the installed version on your machine by executing following command
/usr/libexec/java_home -V
then you might see like below if there are multiple version of JDK installed
11.0.16 (arm64) "Homebrew" - "OpenJDK 11.0.16" /opt/homebrew/Cellar/blabla
1.8.0_292 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 8" /Library/Java/JavaVirtualMachines/bala
Create Env file based your machine, for mac like below create or edit the your system Environment file either .zshenv, .zshprofile etc...
nano ~/.zshenv
export JAVA_HOME=$(/usr/libexec/java_home -v 1.8.0_292)
Then the magic is done, where ever this symlink used all those java refer to version which you set! Happy coding Boys & Girls.

I had a similar situation, and the following process worked for me:
In the terminal, type
vi ~/.profile
Then add this line in the file, and save
export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk<version>.jdk/Contents/Home
where version is the one on your computer, such as 1.7.0_25
Exit the editor, then type the following command make it become effective
source ~/.profile
Then type java -version to check the result
java -version
What is .profile?
From:http://computers.tutsplus.com/tutorials/speed-up-your-terminal-workflow-with-command-aliases-and-profile--mac-30515
.profile file is a hidden file. It is an optional file which tells the system which commands to run when the user whose profile file it is logs in. For example, if my username is bruno and there is a .profile file in /Users/bruno/, all of its contents will be executed during the log-in procedure.

MacOS uses /usr/libexec/java_home to find the current Java Version. One way to bypass is to change the plist file as explained by #void256 above.
Other ways is to take the backup of the java_home and replace it with your own script java_home having the code
echo $JAVA_HOME
Now export the JAVA_HOME to the desired version of the SDK by adding the following commands to the ~/.bash_profile.
export JAVA_HOME="/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home"
launchctl setenv JAVA_HOME $JAVA_HOME /// Make the environment variable global
Run the command source ~/.bash_profile to the run the above commands.
Anytime one needs to change the JAVA_HOME he can reset the JAVA_HOME value in the ~/.bash_profile file.

I wanted to change default java version form 1.6* to 1.7*. I tried the following steps and it worked for me:
Removed link "java" from under /usr/bin
Created it again, pointing to the new location:
ln -s /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/bin/java java
verified with "java -version"
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

JVM version manager

Is there Ruby Version Manager equivalent for the Java world?
I'm looking for tool which allow me to easily download and install a new JVMs and switch between them. For example:
jvm install <version>
jvm list //will list installed JVMs on my system
jvm use jdk1.6 //will switch my env to jdk 1.6 version, etc.

http://www.jenv.be/ will allow this type of control.

SDKMAN! is a similar tool for the Java ecosystem. Supports various Java versions, Scala, Clojure, Kotlin, Groovy, and build tools like Maven and Gradle.
Works on Mac and Linux, with some mentions of support for Windows depending on how hard you are willing to try :)

If you use Ubuntu you can specify which JVM you want to use via command (works only for JVM installed from apt-get or aptitude)
sudo update-alternatives --config java
Or by setting JAVA_HOME. Here is good tutorial:
http://vietpad.sourceforge.net/javaonlinux.html

For the sake of completeness, there are two more - jabba (of which I am the author; written in Go and designed after nvm/gvm/rvm) and jenv (not to confuse with jenv.be; doesn't support installation from oracle but can install from a custom zip).

With JVMs, if you need to switch between them you just need to use a batch file (or powershell script) to manage the classpath and JVM path. You don't need to rely on the system default JVM path and instead just allow your app to point to whatever JVM you like by changing classpath and JVM path environment in the shell that runs the JVM.
For programs that are getting Java location from the Registry, in theory you could use a batch script to update that also.
In this respect Java is way easier than "Ruby version manager".

As it is not (yet) in the list of possibilities, there's also asdf.
asdf does not only provide version management for java, it has plugins for ~400 different languages and tools by default, you can find more on github, or create your own.
Here is an example how to setup a new install (you can also install completion so you don't have to list the versions first). The java plugin is added, a specific version (there are versions for adoptopenjdk, corretto, dragonwell, graalvm, liberica, mandrel, microsoft, openjdk, oracle, sapmachine, semeru, temurin, trava, zulu) is installed and configured to be the global (or local version) to use:
asdf plugin-add java # Add java Plugin
asdf list-all java # List all available java versions
asdf install java openjdk-18 # Install specific jdk version
asdf install java openjdk-17 # Install another jdk version
asdf global java openjdk-18 # Set the global jdk version
asdf local java openjdk-17 # Set the local version for calls from the current directory
asdf uses a file in $HOME/.tool-versions to configure the global selected version. If you call any tool in a directory that has a .tool-versions file with a different version, that one is used (defined with asdf local …).

The trick is to use update-java-alternatives (from the java-common package). The update-alternatives command will not update every one of the symbolic links for various java /bin executables, which is why update-java-alternatives is better.
So to go for OpenJDK 6 to 7, use update-java-alternatives -l to get a list of Java alternatives and then used sudo update-java-alternatives -s java-1.7.0-openjdk-amd64 to switch the JDK.
CAVEAT: The command above might throw the following errors,
update-alternatives: error: no alternatives for mozilla-javaplugin.so.
update-java-alternatives: plugin alternative does not exist:
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
This is because the openjdk plugin is not installed by default. To fix run sudo apt-get install icedtea-7-plugin and rerun update-java-alternatives.