[Dec 7, 2007 Update:  Sun JRE 1.5.0_13 is now certified with the E-Business Suite; see this article for details about the latest certification]

I’m very pleased to announce that the native Sun JRE plug-in version 1.5.0_12 is now certified and Generally Available for use with Release

11i and 12. 

Forms Apps architecture: Logical architecture showing desktop clients running Sun JRE or Oracle JInitiator, connecting via HTTP or HTTPS to Oracle Forms running on the Application Server tier


This is a major step forward.  Up until now, the E-Business Suite Release 11i has required the use of Oracle Jinitiator to access its Forms-based applications.  Release 12 already supported the use of a special version of the native Sun Java Runtime Engine (JRE) plug-in instead of Oracle Jinitiator.

With this certification:
  • E-Business Suite Release 11i users can use Sun’s JRE 1.5.0_12 in place of Oracle Jinitator. 
  • E-Business Suite Release 12 users can use the same JRE 1.5.0_12, instead of being restricted to the special version originally shipped with Release 12.
Coexistence with JInitiator Clients

Oracle E-Business Suite system administrators can now configure their environments to support access to Forms-based applications with either Oracle JInitiator, the native Sun JRE plug-in, or a mix of the two desktop client technologies.

In other words, one set of end-users may continue to use JInitiator to access an E-Business Suite environment.  A different set of end-users may use the native Sun JRE plug-in to access the same E-Business Suite environment.  For example:

Tim has JRE 1.5.0_12 installed exclusively on his PC; Tim doesn’t use JInitiator.  While Roya is logged in to Release 11i via Oracle JInitiator 1.3.1.25, Tim may log into the same Release 11i environment using JRE 1.5.0_12.

This support for coexistence of the two desktop clients allows you to roll out the native Sun JRE to your users in phases.  You don’t need to convert all end-users from JInitiator to the native Sun JRE plug-in at the same time.

Note that your E-Business Suite environment must be set to use either Oracle JInitiator or the native JRE plug-in by default.  Apps sysadmins can

designate specific named end-users to use the “other” (i.e. the non-default) Java client.  There are some restrictions around this, notably for

Discoverer and Workflow users, so this type of mixed-client configuration is designed to smooth your deployment transition rather than as a long-term solution.  If you’re interested in this approach, a careful review of the documented restrictions is worthwhile.

Running JInitiator and the Native Sun JRE Simultaneously

It’s technically possible to run multiple JInitiator and native Sun JRE plug-in  sessions simultaneously on the same PC.  There are two requirements for this:
  • Internet Explorer is being used
  • Each JRE/Jinitiator instance is started in a separate Internet Explorer session
It isn’t possible to run multiple JRE/JInitiator versions simultaneously from the same desktop if Netscape, Firefox, or Mozilla browsers are being used.  These browsers share a single cookie session per desktop, which restricts usage to a single Java version at a time.

What’s Wrong with JInitiator?

Nothing!  JInitiator works fine and will continue to be certified with the E-Business Suite Release 11i (we have no plans to certify JInitiator with Release 12).  However, there are two major reasons for switching your end-users to the native Sun JRE plug-in:
  1. Elimination of conflicts between Oracle JInitiator and other Java virtual machines

    Oracle JInitiator is an authorized version of Sun Microsystems’ Java2 Standard Edition, with extensions required to support Oracle Forms.  Some versions of Oracle JInitiator have known conflicts with other Java virtual machines, including Sun Microsystems’ own plug-in. Using the native Sun Microsystems’ JRE plug-in instead of Oracle JInitiator eliminates those conflicts.
  2. Reduction of desktop client complexity

    Managing multiple Java Virtual Machines on Windows-based desktop clients can be potentially complex. Some Windows-based desktop clients may have three or more Java Virtual Machines installed, including versions from Microsoft, Sun, and Oracle. For example, Microsoft’s Internet Explorer was dependent upon Microsoft’s own Java Virtual Machine at one point in its lifecycle.  Downloading, installing, and maintaining separate Java Virtual Machines can be technically complex and costly for enterprise desktop administrators.
Prerequisites for Release 11i
  • Customers using Oracle Applications 11.5.9 or later
  • Oracle Developer 6i Patchset 18 (6.0.8.27.x) or later
  • Microsoft Windows XP or Microsoft Windows 2000
  • Microsoft Internet Explorer 6.0 and higher
  • Mozilla Firefox 1.0.4 and higher
Windows desktops running the native Sun JRE plug-in can coexist with other Windows desktops running the following Oracle JInitiator releases:
  • JInitiator 1.1.8.x (JDK 1.1 based)
  • JInitiator 1.3.1.x (JDK 1.3 based)
Prerequisites for Release 12
  • Customers using Oracle Applications 12.0 or later
  • Microsoft Windows XP or Microsoft Windows 2000
  • Microsoft Internet Explorer 6.0 and higher
  • Mozilla Firefox 1.5 and higher
Oracle JInitiator isn’t certified or supported for Release 12.

Special Note for Early Adopter Program Participants

We’ve been running an Early Adopter Program for this configuration with a select number of customers since 2004.  The release of this configuration into General Availability marks the end of this Early Adopter Program.

If you’re a participant in our Early Adopter Program, you’re running your Apps 11i environment on either our latest Build 5.1 or an earlier Build, and your end-users are running JRE 1.5.0_07 or earlier.  Now that our Early Adopter Program has concluded, you will need to:
  1. Upgrade your environment to the latest interoperability patch listed in the June 25, 2007 version of Metalink Note 290807.1
  2. Upgrade your end-users’ desktops to JRE 1.5.0_12
Note that JRE 1.5.0_12 resolves the focus-related issue that has existed in all prior JRE releases.  This is a very important upgrade for users running earlier JRE versions.

You’re free to stay on an earlier Build and earlier JRE releases, of course.  However, if you report any problems with an earlier configuration that can’t be reproduced in the Generally Available configuration, you’ll likely be advised to upgrade to the latest configuration.  Likewise, if you report any issues with older configurations that can be reproduced on the Generally Available configuration, you’ll need to upgrade to the Generally Available configuration before you can apply any fixes for these new issues.

References