Java Plug-in Multi-versioning Proposal
Background
Java Plug-in enables enterprise
customers to run their applets using latest Sun's Java Runtime Environment (JRE),
instead of the web browser's default virtual machine. It provides a consistent
Java environment across various platforms and browsers. As customers began
to deploy more and more applets on their Intranet through Java Plug-in, they
encountered various problems:
- They would like to install multiple versions of Java Plug-in on the same
machine to run their applets. Upgrading all the applets to the latest Java
Plug-in release is usually not possible because of resources involved and
project schedule.
- Sun provides patch releases of Java Plug-in and JRE periodically, so
customers will be able to get the latest bug fixes, especially for Y2K and
security bugs. Customers would like to upgrade Java Plug-in and the JRE to
the patch releases automatically through the Java Plug-in installation
mechanism.
The Java Plug-in team envisioned
that customers would usually upgrade to the latest Java Plug-in releases to
leverage the latest Java features, so Java Plug-in was never designed to coexist
with different versions of Java Plug-in in the same machine. Thus, in reality,
when customers would like to have multiple versions of Java Plug-in installed to
support their applets, this becomes a huge problems to both the customers and
the Java Plug-in team.
The reasons why Java Plug-in
cannot coexist with other versions are summarized as follows:
- The same CLSID is used for multiple versions of Java Plug-in for Internet
Explorer.
- The same set of MIME types and DLLs (NPJava*.dll) are used for multiple
versions of Java Plug-in for Netscape Navigator in the same Navigator's
plug-in directory. These DLLs are overwritten when a different version of
Java Plug-in is installed.
- The same registry keys are used for multiple minor versions of Java
Plug-in. For example, 1.1.7, 1.1.8 and 1.1.8-0001 are shared the same set of
registry keys. This makes them impossible to coexist.
- The same registry keys and property files are used for storing Java
Plug-in Control Panel settings in multiple versions of Java Plug-in.
- For Java Plug-in 1.1.x and 1.2.x, the same icon "Java Plug-in Control
Panel" are installed in the Start menu.
- For Java Plug-in 1.3.x, the Java Plug-in Control Panel DLLs are installed
the WINNT/System32 directory.
- The same CAB file and pluginspage are used in the EMBED/OBJECT tag for
minor versions of Java Plug-in.
Solution
Basically, the root of the
multi-versioning problem in Java Plug-in was caused by conflicts in registry
keys, files, resources, etc. Therefore, the solution is basically
to provide unique registry keys, files, resources in every new/patch release of
Java Plug-in:
- Unique CLSID for every new/patch version of Java Plug-in. Customers who
want to use one particular version of Java Plug-in , they will specify this
unique CLSID in the OBJECT tag, so the proper version of Java Plug-in will
be used. It will be stored in
HKEY_CLASSES_ROOT\<clsid>
The CLSID is also stored in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Code Store Database\Distribution
Units\<clsid>
This registry key is used for Internet Explorer exclusively to determine
whether the proper version of Java Plug-in has been installed.
- Unique MIME type and NP*.DLL for every new/patch version of Java Plug-in.
Customers who want to use one particular version of Java Plug-in, they will
specify this unique MIME type in the EMBED tag, so the proper version of
Java Plug-in will be used. Also, this MIME type will be supported in a
NP*.DLL with an unique name for every new/patch version. Therefore,
installing different version of Java Plug-in will not overwrite this unique
NP*.DLL in the Navigator's plugins directory. The MIME type should follow
the convention:
For applet, the MIME type should be
application/x-java-applet;jpi-version=<version
number>,
where the <version number> will include the major, minor and
the patch version number. e.g. 1.1.3-0001
This MIME type is supported in the file
NPJava<modified version
number>.DLL
e.g. for Java Plug-in 1.1.3-0001, the unique MIME type should be
"application/x-java-applet;jpi-version=1.1.3-0001", and it is
supported in the file "NPJava113_0001.DLL" in the Navigator's
plugins directory.
- Unique Java Plug-in registry key for every new/patch version of Java
Plug-in. The main Java Plug-in registry key will be
HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Plug-in\<version number>
where the <version number> will include the major, minor and
the patch version number. e.g. 1.1.3-0001
- Unique Java Plug-in Control Panel registry key and property file for every
new/patch version of Java Plug-in. The main Java Plug-in Control Panel
registry key will be
HKEY_CURRENT_USER\Software\JavaSoft\Java Plug-in\<version number>
where the <version number> will include the major, minor and
the patch version number. e.g. 1.1.3-0001
The property file will continue to be in <user.dir>\.java.
However, the filename will be unique in every new/patch release as follows:
<user.dir>\.java\properties_<version number>
where the <version number> will include the major, minor
and the patch version number. e.g. C:\WINNT\System32\Profiles\stanleyh\.java\properties_113_0001
Since Java Plug-in 1.3, a new file plugin.trace is created
automatically in <user.dir> when Java Console is enabled. Its
purpose is to capture the same messages that are displayed in Java Console
into a single file. In order to avoid conflict, this file needs to be unique
in every new/patch release as follows:
<user.dir>\.plugin<modified version number>.trace
where the <modified version number> will include the major, minor and
the patch version number. e.g. plugin113_0001.trace
- Unique Java Plug-in Control Panel icon in Start Menu for Java Plug-in
1.1.x and 1.2.x. When Java Plug-in is installed, it will install an icon
with an unique name:
Java Plug-in Control Panel <version number>
where the <version number> will include the major, minor and
the patch version number. e.g. "Java Plug-in Control Panel
1.1.3-0001"
- Unique Java Plug-in Control Panel in Windows Control Panel for Java
Plug-in 1.3.x. When Java Plug-in 1.3.x is installed, two DLLs (plugincpl.cpl,
etc) will be installed in C:\Windows\System32 directory. By providing a
unique file names to the Java Plug-in Control Panel DLLs in every new/patch
release, users will be able to launch the Control Panel that comes with a
particular version of Java Plug-in. The filename for the DLL will be
plugincpl_<modified version number>.cpl
where the <modified version number> will include the major, minor and
the patch version number. e.g. plugincpl_113_0001.cpl
-
Unique CAB file and pluginspage URL for every new/patch version of Java Plug-in. As mentioned in #1 and #2 above, and new CLSID and MIME type will be provided for every new/patch version of Java Plug-in. Therefore, it also requires a new CAB/pluginspage URL for these releases as well. Moreover, the information specified in
HKEY_LOCAL_MACHINE\Software\Microsoft\Code Store Database\Distribution Units\<clsid>\DownloadInformation
HKEY_LOCAL_MACHINE\Software\Microsoft\Code Store Database\Distribution Units\<clsid>\InstalledVersion
will need to reflect these unique CAB URLs.
For example,
<OBJECT classid=clsid:EEEEE840-044E-11D1-B3E9-00805F499D93
codeBase=http://java.sun.com/products/plugin/1.1.3-0001/jinstall-113-0001-win32.cab#Version=1,1,3,1
height=300 width=300>
<PARAM name=code value="XYZApp.class">
<PARAM name=type value="application/x-java-applet;jpi-version=1.1.3-0001">
<EMBED type="application/x-java-applet;jpi-version=1.1.3-0001" code=XYZApp.class
width=300 height=300
pluginspage="http://java.sun.com/products/plugin/1.1.3-0001/plugin-install.html">
</OBJECT>
The CLSID for 1.1.3-0001 is EEEEE840-044E-11D1-B3E9-00805F499D93, and the
MIME type is "application/x-java-applet;jpi-version=1.1.3-0001". The
CAB and the pluginspage URL point to unique locations that provide 1.1.3-0001
for download. Notice that the version number for the CAB file should include
the major, minor and the patch number of the release. For example, for
1.1.3-0001, the CAB version should be 1,1,3,1.
Unique registry keys for every new/patch release JRE/JDK. Currently,
installating multiple versions of Java Plug-in will overwrite the JRE/JDK
registry keys because of the way JRE/JDK was written. Therefore, even if
Java Plug-in no longer overstep other versions, the JRE/JDK that Java
Plug-in bundles with will still overstep each other. It is important to
provide unique JRE/JDK registry keys as follows:
HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Runtime Environment\<version
number>
HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Development Kit\<version
number>
where the <version number> will include the major, minor and
the patch version number. e.g. 1.1.3-0001
The purpose of these keys are for Java Plug-in to locate the proper version
of JRE/JDK. Also, users will be able to select these JRE/JDK from the Java
Plug-in Control Panel.
Collision detection will be supported in every new/patch version of
Java Plug-in. Basically, multiple versions of the Java Plug-in cannot be run
in the same browser sessions. Therefore, it is extremely important to warn
the users if it happens and then fails. The collision detection works as
follows: when Internet Explorer or Netscape Navigator loads up Java Plug-in,
it will create a global mutex with a name that contains the browser process
ID. When another applet is loaded through a different version of Java
Plug-in, Java Plug-in will check for this mutex to determine if another
version of Java Plug-in has been loaded into the same browser process. If
so, it will popup a warning dialog and fail to load the applet. Otherwise,
there is no other version of Java Plug-in running, and the applet loads.
Outstanding issues
- This scheme should work with Win32. How about other platforms like
Solaris? Do we expect customers to need multiple versions of Java Plug-in
coexist on these platforms?
- This scheme allows even multiple patch releases of Java Plug-in to coexist
on the same machine. e.g. 1.1.3-0001 and 1.1.3-0005 will coexist on the same
machine. Is it really necessary? If not, we may be able to make the solution
easier than the one in this proposal.
- The patch release number for Win32, Solaris or other platforms may not be
in sync. Therefore, customers may need 0001 patch for Win32, while they may
need 0008 for Solaris. In this case, JavaScript should be used to emit the
proper EMBED/OBJECT tag, depending on the platform.
- This scheme will work if and only if the unique CLSID, MIME type, etc are
used in HTML. If the old CLSID and MIME type are used, we will still run
into the same old problem.
- When Jump comes out this summer, it will allow users to install JRE/JDK
randomly on the machine, and this will break Java Plug-in because of this
multi-versioning problem. This is extremely important to get a solution in
place and put them in the next patch release for 1.1.x, 1.2.x and 1.3.x.
Also, it is also desirable to obsolete any previous patch versions that
don't have this solution.