JDK-6625142 : Auto-download support for particular JRE version in applet tag
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2007-11-02
  • Updated: 2010-04-04
  • Resolved: 2008-02-01
Related Reports
Relates :  
JDK-6625140 - Consider expanding jpi-version support in new plug-in
Relates :  
JDK-6606784 - Add support for launching applets from JNLP files
Description
In the new plug-in we have added support for selecting a particular JRE version in the applet tag via the java_version parameter. However, unlike the classid attribute in the object tag in Internet Explorer (for example), there is currently no way to specify an auto-download location for this JRE version if it is not installed.

The object and embed tags, typically used in IE and Firefox, respectively, have different support mechanisms for auto-download and auto-installation of a particular version of the JRE. More experimentation is needed to see how well these tags interact with the new Java Plug-In. In IE, for example, since the new plug-in already registers CLSIDs corresponding to many update releases of previous JRE families, it is unclear whether auto-download of the release will be triggered if it is not present, or whether the new plug-in will be used.

The applet tag is more browser-independent and we have better control over its implementation. We should consider supporting a mechanism like the codebase parameter to the object tag for (reasonably) portable auto-download and auto-installation of a targeted JRE version. This might be important for corporate customers.
Further investigation indicates that this portable auto-download mechanism is actually a requirement; there is no other way to achieve this functionality using the CLSID mechanism in IE or the MIME type in Firefox. To understand this, consider the CLSID case. We pre-register the new Java Plug-In under all known CLSIDs, so when the request comes in to launch a particular applet with a specific CLSID, it is redirected to the new Java Plug-In by the browser, and even if a .cab file were pointed to by the codebase, it would not be auto-downloaded by the browser since there is already a handler for this CLSID. Therefore it must become the responsibility of the new plug-in to automatically download new JREs.

The initial thinking is to support a new java_href parameter to the applet, object and embed tags alongside the new java_version parameter, which would work in similar fashion to the href parameter in the java tag in the JNLP spec. This will point to the download bundle for the desired version of the JRE upon which to launch the applet.

More thinking is needed in this area, but strawman documentation will be written on this assumption.
Comments
EVALUATION Attempts to implement this revealed that the auto-download code currently in the deployment workspace is inextricably tied to Java Web Start. Instead of implementing auto-download for the old-style applet tag, we will build on the new support for launching applets from JNLP files, which will soon support auto-download of the JRE in the context of applets. Note that not supporting auto-download for the old-style applet tag in the new Java Plug-In is not a regression relative to the old Java Plug-In. Since the introduction of SSV in the old Java Plug-In, auto-download of an earlier JRE version has not been supported. The only option was to manually download and install the desired JRE version. Overall, with the forthcoming auto-download capability in the JNLP support in the new Java Plug-In, the user experience will be more automatic than in the old Java Plug-In, and will be equivalent to that of Java Web Start. Closing as "Will Not Fix".
01-02-2008