Judging from your blog comments and emails, many of you are in the difficult situation of having to support end-users with multiple Java plug-ins on the same Windows PC. This is a little more complicated than the days when Oracle JInitiator was the only thing we had to worry about. Let's review what's possible today and discuss the implications for your rollouts. Supporting Multiple Java-Based Applications
A substantial number of Oracle E-Business Suite modules are based on Oracle Forms. Different E-Business Suite releases are certified with different Java clients:
- Release 11i: Oracle JInitiator and native Sun Java plug-in
- Release 12: Native Sun Java plug-in only
Many large organizations run other Java-based applications in addition to Oracle Applications. These third-party applications may require different Java desktop client versions, often older releases like Java 1.3 or Java 1.4.
The problem arises when those software vendors don't upgrade their certifications to the latest Java release. You may end up with a situation where your E-Business Suite environment may require 1.5.0_13 but other applications require 1.4.2_08.What's Possible With JInitiator
Oracle JInitiator supports multiple installations of different JInitiator versions on the same Windows PC. Each specific JInitiator version can be separately invoked by the calling Forms-based application. This is called static versioning
This allows one Oracle Forms-based application to use a particular Oracle JInitiator version, while another application can invoke a different JInitiator version.Static Versioning Not Directly Supported With Native Sun Plug-In
Sun's native Java plug-in from version 1.5.0_06 and later does not support static versioning by default when using Microsoft Internet Explorer. If you have multiple versions of the JRE plug-in installed on your desktop, the latest version installed will run.
Another Potential Problem: Automatic Upgrades
- If Oracle E-Business Suite is set up to run JRE 1.5.0_12 on the server and both JRE 1.5.0_12 and JRE 1.5.0_13 are installed on the desktop, the environment will incorrectly launch using JRE 1.5.0_13 rather than JRE 1.5.0_12.
- If Oracle E-Business Suite is set to run on JRE 1.5.0_13 on the server and both JRE 1.5.0_13 and JRE 1.6.0 are installed on the desktop, the environment will incorrectly launch using JRE 1.6.0 rather than JRE 1.5.0_13.
The native Sun JRE plug-in's configuration will usually be set to download the latest Java release automatically. If your users have installed version 1.5.0_12 with automatic updates enabled, then those desktops will upgrade themselves automatically to the latest release, say, 1.5.0_13 or even 1.5.0_14.
It's probably a good idea to disable automatic updates if you're uncomfortable with this, for the following reasons:
The Bottom Line
- These automatic updates may outstrip your software vendors' certifications, including Oracle.
- Desktop administrators hate it when their users' desktops change unpredictably.
If you're faced with the difficult situation where you're struggling with different Java versions required by different vendors, I'm afraid that you don't have many palatable options. These include:
Option 1. Run MS IE with a registry modification
If your end-users are running Microsoft Internet Explorer (IE), there's a possible workaround. The catch? You've got to make a manual change to the Windows Registry for each of your end-users' desktops. If you have the stomach for that kind of thing, you can find the details in the respective Release 11i or 12 documentation listed in the References section below.
Option 2. Give the later versions a tryReferences
Now that we've certified the E-Business Suite with Java 1.5.0_13 with both Release 11i and 12, it's reasonably assured that later versions will work equally well with Oracle Apps. Our certification cycles for these native Java plug-ins are getting faster, and we're working on later 1.5.x versions as well as 1.6 now.
Our standing recommendation is to wait for Oracle's certification with Apps before rolling out later Java releases. However, if you really don't have the luxury of waiting for our certifications to complete, you can always upgrade a test PC to the target JRE version of your choice and give it a try. Thorough system testing is a good idea before rolling out an uncertified JRE version to your Apps users.
From a support perspective, remember that Oracle Support will do their best to answer your questions about the use of uncertified Java plug-in versions with the E-Business Suite. Bear in mind that if you encounter problems that can't be reproduced with the certified Java plug-in versions, Oracle Support will likely recommend that you revert to a certified configuration.
Option 3. Share your pain
The pain from this situation can arguably be lessened if all software vendors -- including Oracle, naturally -- keep their certifications current with the latest Java plug-ins available.
It's the slower vendors still stuck on, say, Java 1.4.2_08 that are creating the real pain for you. If I were in your shoes, I wouldn't be shy about making sure that those vendors feel your pain, too. Log service tickets with them and escalate your concerns with your vendor account managers.