Earlier this year, as of ORDS 22.1.0, the minimum supported Java version moved to Java 11. The ORDS command line script finds the Java Runtime Environment on your machine based on path or JAVA_HOME environment variable and in the majority of cases that works out fine.
What do you do if you need to keep a different, perhaps older, Java Runtime Environment in the path? You might be using some other application or utility which expects a JRE which is incompatible with ORDS.
The simple answer is that the ORDS command line script does go looking for a JRE in the directory where you have extracted the ORDS distribution. If you have extracted ORDS to /opt/oracle/ords/22.2.0/ then the command line shell script goes looking in /opt/oracle/ords/22.2.0/jre/ for a Java Home.
Symbolic link makes it easy
The most straight forward way to provide this Java Runtime Environment home for ORDS to use is to define it using a symbolic link. That way you are not duplicating files and you can point to a new JRE version whenever suits.
ln -s /Library/Java/JavaVirtualMachines/jdk-17.0.4.jdk/Contents/Home /opt/oracle/ords/22.2.0/jre
Seeing it in action
In my environment the default JAVA_HOME is Java 11 so when I start up ORDS in standalone mode that is what is used.
That is with no Java Runtime Environment specified in the ORDS directory…
/opt/oracle/ords/22.2.0 ├── FUTC.txt ├── bin ├── docs ├── examples ├── icons ├── index.html ├── lib ├── license.txt ├── linux-support ├── ords.war └── scripts
In my case I also have a more recent Java 17 JRE which I can link to. See the earlier ln -s command for syntax. Now that I have that link in place…
/opt/oracle/ords/22.2.0 ├── FUTC.txt ├── bin ├── docs ├── examples ├── icons ├── index.html ├── jre -> /Library/.../jdk-17.0.4.jdk/Contents/Home ├── lib ├── license.txt ├── linux-support ├── ords.war └── scripts
… the version of Java used by ORDS in standalone mode, or any command for that matter, is locked in. The PATH could change, the JAVA_HOME could change, but this ORDS will use this specified JRE.
That simple approach provides more options for running different Java applications which may have very specific version requirements.