Why isn’t the newest JDK in this Oracle Release Update?

Quick blog post only since I received this question 3x this week in various ways from customers. Why isn’t the newest JDK in this Oracle Release Update? Let me try to answer and explain it.

Why isn't the newest JDK in this RU?

Photo by Jan Kronies on Unsplash

JDK in the Oracle Home

Actually, when you look at your Oracle Home, you will find a subdirectory:

/u01/app/oracle/product/19/jdk
$ tree -L 1
.
├── bin
├── COPYRIGHT
├── include
├── javafx-src.zip
├── jmc.txt
├── jre
├── jvisualvm.txt
├── legal
├── lib
├── LICENSE
├── README.html
├── release
├── THIRDPARTYLICENSEREADME-JAVAFX.txt
└── THIRDPARTYLICENSEREADME.txt

And in the bin directory, there is the java exec we use for instance to run AutoUpgrade.

/u01/app/oracle/product/19/jdk/bin
$ ./java -version
java version "1.8.0_401"
Java(TM) SE Runtime Environment (build 1.8.0_401-b10)
Java HotSpot(TM) 64-Bit Server VM (build 25.401-b10, mixed mode)

My database home is Oracle 19.23.0, the most recent as of now while I write this.

But when I check MOS Note: 2584628.1 – JDK and PERL Patches for Oracle Database Home and Grid Home and compare to my environment, the newest JDK is JDK8u411 while my currently installed one is only JDK8u401.

 

Why is the JDK in the RU not the newest?

At first, JDK Patching happens with every RU since January 2020. This was an excellent improvement to the releases before since the JDK did not get updated as part of the regular patching. But when you check the JDK version, you usually see that it isn’t the newest but an “n-1” version instead.

In reality, apart from “not being on the newest” the challenge you are faced with often are security check scripts which will flag the JDK delivered with a brand new Release Update as “outdated”.

Still, I fear that there is no way out.

When we build a Release Update (RU), there is a code freeze. And this code freeze is typically weeks before the RU gets released. Since the RU is bundled with a JDK, and the JDK is used by some of our tool (such as AutoUpgrade for instance), we can bundle and test only with the most recent JDK being available at the time of the code freeze.

Unfortunately, at release date of the RU, this JDK then will be obviously not the newest since at the same date of the release of the RU, a new JDK gets released as well. Due to the fact that there is a lot of testing done, there is no option to exchange the JDK just a day before the RU release. We need to ship the “n-1” version, the one which was current when the code freeze for the RU has happened – and the one we completed all test runs with.

I hope this clarifies a recurring question – and let me finally state that JDK and OJVM or JVM are different topics, just for the records 🙂

 

Further Links and Information

–Mike

Share this: