Wednesday, January 8, 2020

EPM 11.2 References to Java 6 Not Completely Eradicated

In troubleshooting why Planning RMI Registry won't bind to port 11333 and throws a "could not find the service start class" error in the Windows Event Viewer, I did some digging and noticed several places where either jdk160_35 or JRE\Sun\1.6.0 are still referenced.  This might not be my problem, but it led to some interesting research.

Without further ado:


if exist "%EPM_ORACLE_HOME%\..\jdk160_35" (
set JAVA_HOME=%EPM_ORACLE_HOME%\..\jdk160_35
if exist "%EPM_ORACLE_HOME%\common\JRE\Sun\1.6.0" goto okSetJRE160


set JVM_HOME=%EPM_ORACLE_HOME%\common\JRE\Sun\1.6.0\bin\client


set JAVA_HOME=%EPM_ORACLE_HOME%\..\jdk160_35


Now let's pick this apart a little.

%EPM_ORACLE_HOME%\..\jdk160_35 does not exist in EPM 11.2.  The setJavaRuntime.bat script thus fails over to the Sun 1.6.0 JRE instead.

%EPM_ORACLE_HOME%\common\JRE\Sun\1.6.0\bin\client does exist in EPM 11.2.  In the same JRE\Sun folder there's also a subdirectory for Java 8 in 11.2.  In the case of InstallHyperionNTServiceRMI.bat, however, we can't just swap out the reference to 1.6.0 to Java 8, as if you look closely at the script, all it wants from the Sun JRE (I believe) is jvm.dll, which resides within a slightly different subfolder.

For some of my customers, the presence of %EPM_ORACLE_HOME%\common\JRE\Sun\1.6.0 will present a problem.  Their IT shops run vulnerability scanners that seek out all occurrences java.exe considered to be vulnerable.

It ought to be OK to swap out the references to jdk160_35 with jdk1.8.0_181, but I haven't had time to fully regression test this.  In 11.1.24, we'd swap jdk160_35 with a generically named jdk7, so as to reduce further script maintenance when the quarterly Java patches come out.  I'm inclined to do the same thing for jdk8, but there are many other things to look into before I pull the trigger on that (Windows Registry, deployment scripts, etc...)


  1. Hi Dave,

    All the Essbase clients are searching for Java 6 folders in the installed directory. Even in the FDMEE process log, there is a line saying "The JavaHome is set to %EPM_ORACLE_HOME%\..\jdk160_35"

  2. Very disappointing that they didn't couldn't get JDK6 references removed. It should be safe to manually clean up I would expect though.