Issues with Java SE 8u121 MSI and REMOVEOLDERJRES

Oracle released the 8u121 update for Java SE last week with a little surprise for anyone who installs/updates the Java Runtime Environment (JRE) using the MSI file with the REMOVEOLDERJRES option. If you set REMOVEOLDERJRES to 1, the setup will find and remove any existing versions of the JRE that are installed. Doing so ensures that you don’t have any older unpatched versions on your system. The 8u121 setup behavior has changed, however, which can cause issues if you install both the 32 and 64-bit versions on your systems.

The Problem

Normally, the REMOVOLDERJRES option only removes installed JRES that match the architecture for the version you’re installing. Install 32-bit Java, and it will remove installed 32-bit versions. Install 64-bit Java, and it will remove installed 64-bit versions. When you use this option with 8u121, however, it removes both 32 and 64-bit versions, including any 8u121 JREs that are installed.

I encountered this behavior while testing a script I use for installing Java during MDT deployments. It installs the 32-bit version first, followed by the 64-bit version. After running the setup, only the 64-bit version was present. The setup logs indicated that both version were successfully installed. I reversed the order, and ran the setup again. This time only the 32-bit version was installed, yet both logs indicated successful installs. The second install was removing the first. But why? In this case, the guilty party was the Upgrade table in the MSI.

The Cause

The Upgrade table contains the information needed for the setup process to find installed programs that are affected by the installation.  I opened the MSI file using Orca from the Windows SDK, and verified the Upgrade tables for 8u121 were the issue.

Looking at the Upgrade table for the 64-bit version of 8u111, you can see that all but one of the UpgradeCodes are for 64-bit versions. The only 32-bit version is for Java 9 which is in Early Release, although I’m not sure why. You can tell which type the Upgrade Code is for by looking at the last group of numbers; it will contain either “32” or “64” in positions six and seven. For example, “{57BDA5C6-443C-4D65-B233-282396418000}” is for a 64-bit version of Java SE 8 (18 = Java 8). The highlighted “64” would be “32” for a 32-bit version.

Switching to the Upgrade table for 8u121, you can see we have several additional entries now, with both 32-bit and 64-bit versions.

The Workaround

To restore the previous setup experience, use Orca or another MSI editor to remove rows from the Upgrade Table which don’t match the architecture of the MSI file. Edit the jre1.8.0_12164.msi file and remove any rows for 32-bit versions (UpgradeCode GUID contains “32” as described earlier), and edit the jre1.8.0_121.msi file remove any rows for 64-bit versions (UpgradeCode GUID contains “64”).

I’m not sure if Oracle intended to change the setup behavior in this way, or if this was a mistake. It wouldn’t be the first time they’ve broken the REMOVEOLDERJRES functionality, so my money is on this being a bug. We’ll have to wait and see if they correct this in the next update.