The Latest Technology Stack News Directly from EBS Development

  • December 25, 2007

Running Multiple Java Plug-Ins on the Same Windows PC

Steven Chan
Senior Director

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.

Sun Java Website screenshot: Screencap of Sun's Java SE website

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.

For example:
  • 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.
Another Potential Problem:  Automatic Upgrades

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:
  • These automatic updates may outstrip your software vendors' certifications, including Oracle.
  • Desktop administrators hate it when their users' desktops change unpredictably. 
The Bottom Line

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 try

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.

Related Articles

Join the discussion

Comments ( 4 )
  • coldclimate Tuesday, December 25, 2007

    Steve man, it's Christmas day. Forget multiple installs, and enjoy a bit quality time!

  • Steven Chan Wednesday, December 26, 2007

    I'm grateful for publishing queues, where one can appear to be working even on days like Christmas when right-minded folks are at home with their family...  Cool blog, by the way.  Case Wook, indeed. ;-)Regards,Steven

  • Steven Chan Thursday, February 7, 2008

    Dawna,Thanks for letting me know about this. This strikes me as unusual but unsurprising.  Sun's new policy appears to be increasingly leaning towards forcing JRE upgrades on users in nearly all scenarios.  Sun may choose to enforce this more strongly in future versions, too.From Oracle's

    perspective, the best thing we can do is switch from certifying specific JRE

    versions for the E-Business Suite to specifying minimum versions,

    instead.  This will permit E-Business Suite users to run any JRE release above

    the minimum, even later ones that Oracle hasn't explicitly tested with the

    E-Business Suite.This certification and support policy change is likely to come sooner than later, and hinges upon the completion of our certification work with JRE 1.6.0_03.  Watch this space for more news of this front soon.Regards,Steven

  • Dawna Roberts Thursday, February 7, 2008

    Steve, We have been running with JRE 1.5.0_13 for a few months now and turned off the Java automatic update rather than update the registry to enable static versioning.

    Since the implementation we have been struggling to figure out why certain PC's seemed to get their Java autoupdate turned back on. We found that autoupdate is turned back on when different users login to the same PC - for more info see forum entry below:


    We are now working on a script that our users will run to update their registry to turn on static versioning. If we had been aware of this autoupdate issue we would have chosen this route long ago.

    Just thought I would let you know - maybe the upgrade note 290807.1 could be updated to reflect this issue so that other users will be fully informed regarding this autoupdate issue?

    Thanks for everything, Dawna.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.