P3 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.
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.
Attachments
Issue Links
- relates to
-
JDK-6606784 Add support for launching applets from JNLP files
-
- Closed
-
-
-
- Closed
-