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:

\Oracle\Middleware\EPMSystem11R1\common\config\11.1.2.0\setJavaRuntime.bat

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

\Oracle\Middleware\EPMSystem11R1\common\RMI\11.1.2.0\InstallHyperionNTServiceRMI.bat

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

\Oracle\Middleware\EPMSystem11R1\products\FinancialManagement\Utilities\MetadataMerge\MetadataMerge.bat

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...)