Develop Reference

Can't set JAVA_HOME dynamically on macOS Catalina

tl,dr;
Doing export JAVA_HOME=$(/usr/libexec/java_home -v 14) once JAVA_HOME was already set won't change active java
Steps
set JAVA_HOME first (for example with export JAVA_HOME=$(/usr/libexec/java_home -v 11)):
$ echo ${JAVA_HOME}
/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
$ java -version
openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)
Try to set it to different version (for example export JAVA_HOME=$(/usr/libexec/java_home -v 14)) - it still uses previously set java (even though JAVA_HOME was updated):
$ echo ${JAVA_HOME}
/Library/Java/JavaVirtualMachines/adoptopenjdk-14.jdk/Contents/Home
$ java -version
openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)
I'm not sure why it's not working now - it was working just fine a while back (I'd say 2-3 months ago)
There is a seemingly similar topic (Can't set JAVA_HOME on Catalina) but it boils down to different shell. In my case I'm using same shell - bash from brew:
$ bash -version
GNU bash, version 5.0.18(1)-release (x86_64-apple-darwin19.5.0)
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Seems update JAVA_HOME is not getting reflected in PATH variable.
So, please update PATH variable also and keep the updated JAVA_HOME as the first element in the export PATH command

OK, I finally managed to solve the issue. As other have pointed out, everything has to do with PATH variable. And I indeed had JAVA_HOME/bin in there… which causes the problem. Today during an update I notice that openjdk brew formula had this comment:
keg_only "it shadows the macOS `java` wrapper"
And things immediately "clicked". After searching a bit I found Why isn't java wrapper not picking up the right version specified in JAVA_HOME on macOS? which confirmed the issue. By including JAVA_HOME in the PATH in my .profile file I was breaking native macOS functionality of it's java wrapper, which selects active java version based on currently set JAVA_HOME.
This is my example session (from opening the shell and having export JAVA_HOME=$(/usr/libexec/java_home -v 11) in the .profile file) -- I have default from the profile, then I set explicitly JAVA_HOME and it switches java version on the fly:
$ java -version
openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)
$ export JAVA_HOME=$(/usr/libexec/java_home -v 14)
$ java -version
openjdk version "14.0.2" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 14.0.2+12)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 14.0.2+12, mixed mode, sharing)

Setting $JAVA_HOME as opc, not accessible as oracle

I am currently with installing and integrating a couple of software on Linux, and I'm very new to Linux. One of the software refuses to run and instructs me to properly set $JAVA_HOME. But I have set $JAVA_HOME! However, when I check the $JAVA_HOME and java -version tests to see if I have done it correctly, it only produces the correct answer when I'm logged in as opc. The permissions of the software I am trying to install is oracle. Do I need to set $JAVA_HOME again when I'm logged in as oracle? And why?
[opc#mydir ~]$ $JAVA_HOME
-bash: /u01/jdk-11.0.3/: Is a directory
[opc#mydir ~]$ java -version
java version "11.0.3" 2019-04-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode)
[opc#mydir ~]$ sudo su oracle
[oracle#mydir opc]$ $JAVA_HOME
[oracle#mydir opc]$ java -version
bash: java: command not found

Environment variables (such as $JAVA_HOME) are set per process. For shells, you'd usually have some initialization script (like .bashrc) that sets all the relevant variables for the current session. You should copy the initialization of $JAVA_HOME you have in the opc user to the oracle user too.

MacOSX 10.11.4: which java version is in use

I am aware this might look duplicated, but I don't seem to find the answer that I am seeking (perhaps is too trivial).
I just downloaded java from the oracle site and I read this:
$java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
Then I added this to my .bash_profile file:
# Java
export JAVA_HOME="`/usr/libexec/java_home -v 1.8`"
so that:
$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home
So far so good.
Now when I type:
$ which java
/usr/bin/Java
Which I think is the default installation (?, I really have no experience in Java)
At this stage, I don't know if I have to simlink:
sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/bin/java /usr/bin
or if the simlink was establish during the java installation. I am going to start installing a series of things that depend on java, so I would like to make sure I understand this before moving on.
Thanks!

What you've done will work. From my system:
$ /usr/bin/java -version
java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)
It uses the java_home command you used, which depends on the Java part of the System Preferences application. So if somehow you have the "wrong" version in use, you can fix it there. But by default, it seems in my experience to use the latest version (man java_home doesn't really say).

Java Screen with Custom JAVA_HOME and LD_LIBRARY_PATH

I have a appilcation that needs Java 32bit on my Debian 64bit server. Is running fine now with this in the .profile or in the SH file.
export JAVA_HOME=/usr/lib/jvm/jdk1.8.0_25/
export LD_LIBRARY_PATH=.:$JAVA_HOME/jre/lib/i386/server:$JAVA_HOME/jre/lib/i386/client:/usr/local/lib
However, when I to start it over screen it simply don't load the Java path and the LD lib path.
Anyone has a idea how to solve this problem?

Please, give me the results the next commands in your console
java -version
and
echo $JAVA_HOME
echo $LD_LIBRARY_PATH
Do you have this in you environments variables?
env | grep JAVA
In my case I have this
user:$ java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
user:$ echo $JAVA_HOME
/opt/jdk/jdk1.8.0_25
user:$ env | grep JAVA
JAVA_HOME=/opt/jdk/jdk1.8.0_25

Setting the JVM via the command line on Windows

Is it possible to specify the JVM to use when you call "java jar jar_name.jar" . I have two JVM installed on my machine. I can not change JAVA_HOME as it may break code that is all ready running.
Kind Regards
Stephen

Yes - just explicitly provide the path to java.exe. For instance:
c:\Users\Jon\Test>"c:\Program Files\java\jdk1.6.0_03\bin\java.exe" -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)
c:\Users\Jon\Test>"c:\Program Files\java\jdk1.6.0_12\bin\java.exe" -version
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
The easiest way to do this for a running command shell is something like:
set PATH=c:\Program Files\Java\jdk1.6.0_03\bin;%PATH%
For example, here's a complete session showing my default JVM, then the change to the path, then the new one:
c:\Users\Jon\Test>java -version
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
c:\Users\Jon\Test>set PATH=c:\Program Files\Java\jdk1.6.0_03\bin;%PATH%
c:\Users\Jon\Test>java -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)
This won't change programs which explicitly use JAVA_HOME though.
Note that if you get the wrong directory in the path - including one that doesn't exist - you won't get any errors, it will effectively just be ignored.

You should be able to do this via the command line arguments, assuming these are Sun VMs installed using the usual Windows InstallShield mechanisms with the JVM finder EXE in system32.
Type java -help for the options. In particular, see:
-version:<value>
require the specified version to run
-jre-restrict-search | -jre-no-restrict-search
include/exclude user private JREs in the version search

yes I often need to have 3 or more JVM's installed. For example, I've noticed that sometimes the JRE is slightly different to the JDK version of the JRE.
My go to solution on Windows for a bit of 'packaging' is something like this:
#echo off
setlocal
#rem _________________________
#rem
#set JAVA_HOME=b:\lang\java\jdk\v1.6\u45\x64\jre
#rem
#set JAVA_EXE=%JAVA_HOME%\bin\java
#set VER=test
#set WRK=%~d0%~p0%VER%
#rem
#pushd %WRK%
cd
#echo.
#echo %JAVA_EXE% -jar %WRK%\openmrs-standalone.jar
%JAVA_EXE% -jar %WRK%\openmrs-standalone.jar
#rem
#rem _________________________
popd
endlocal
#exit /b
I think it is straightforward. The main thing is the setlocal and endlocal give your app a "personal environment" for what ever it does -- even if there's other programs to run.

If you have 2 installations of the JVM.
Place the version upfront.
Linux : export PATH=/usr/lib/jvm/java-8-oracle/bin:$PATH
This eliminates the ambiguity.