EAS Console 11.1.2.4.044, EPM 11.12.4.x, and Java

One of my colleagues hit the following issue in his Hyperion / Oracle EPM 11.1.2.4 system earlier today, and reached out for help.  We got it fixed in just a few minutes, and here's the fix.

Root cause:  You've just patched your Essbase Suite to 11.1.2.4.044, uninstalled your EAS Console and installed the new one.  The EPM servers themselves are still running 11.1.2.4.x and an older version of Java.  The issue described herein doesn't apply to EPM 11.2.x.

Symptom:  On a server (we often test directly on the servers), we double-click the EAS Console thick client launcher, and see a message that looks like this:

You are using older java version 1.7.0_***

Install JDK8 and set JAVA_HOME variable to JDK8 installed location

Depending upon the status of your EPM 11.1.2.4 system, that first line will say either 1.6.0_updatelevel or 1.7.0_updatelevel.

I advise against following some of the blogs and tutorials online concerning this issue.  Here's why:

The blogs and tutorials are essentially telling you to use the Windows Control Panel to set a JAVA_HOME variable that points to the parent folder of a Java 8 "\java\bin" folder.

Don't do this on an 11.1.2.4 server!

11.1.2.4 isn't fully certified for Java 8.  Setting a JAVA_HOME variable that's pointing to a Java 8 could spell disaster the next time you start up Hyperion services or run Hyperion tools.  This entirely depends upon how your EPM system is setup.  Some EPM Infrastructure consultants can get... creative.  In some cases, the WebLogic scripts and other EPM software check if a JAVA_HOME variable is already set, and if so, it sets the variable for the process being started to whatever \Oracle\Middleware\EPMSystem11R1\common\config\11.1.2.0\setJavaRuntime.bat defines.

I'd need to spin up one of my mothballed 11.1.2.4 sandboxes to see if this situation breaks the system or not.  As I'm focusing exclusively on EPM 11.2.x now, I might not have time for this.  Perhaps others can test and comment below!

I'm also concerned about other software IT or anyone else may have installed on the server.  They might not like a JAVA_HOME pointing to a Java 8.

Quick Solution: Download a Java 8 from Oracle Support.  EAS Console doesn't require a JDK to function, so you can grab your choice of either JRE 8 or JDK 8.  Install it and let it go to the C: drive using the default suggested directory location.

Again, let it install to the C: drive.  Don't be tempted to overlay the jdk in your \Oracle\Middleware folder.

Now launch Windows Explorer and navigate to the Java folder you installed on C.  Copy the complete folder path to your clipboard, such as C:\Program Files\Java\jdk1.8.0_xxx

Now the final step.  Edit the EAS launcher script.  By default it would be 

\Oracle\Middleware\EPMSystem11R1\products\Essbase\eas\console\bin\admincon.bat

Look for these lines:

IF DEFINED JAVA_HOME (

    set PATH=%JAVA_HOME%\bin;%PATH:)=^)%

)

Immediately before this, add 1 new line like this:

SET JAVA_HOME="C:\Program Files\Java\jdk1.8.0_xxx"

You need those double quotes due to the space in your path.

Save the script and you're ready to rock & roll.

No messing around with global environment variables, potentially interfering with other apps.  Congratulations, you've just fixed your EAS Console!

Addendum: if on a client workstation, be very wary about installing Oracle Java there.  There's a chance one could run afoul of an Oracle Java license compliance audit, especially if the end-user starts using that Oracle Java for non-Oracle products.  As a workaround for this, Red Hat OpenJDK8 is an acceptable solution.  As OpenJDK is open source and legally free to distribute, you won't run into license compliance issues on non-Hyperion servers.  

I'm no lawyer and cannot speculate on how an end-user's workstation would be treated.... the user is accessing a properly-licensed Oracle product, EAS Console, so there ought not be an issue here.  But again, you don't know what'll happen on that workstation after you walk away!