JDK-6667020 : Code parameter in applet tag should not override main-class for JNLP launched applets
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-02-23
  • Updated: 2010-09-08
  • Resolved: 2008-05-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u10 b21Fixed
Related Reports
Relates :  
In the new Java Plug-In's support for launching applets directly from JNLP files, we assumed that the "browser knows best" and had various attributes from the applet tag override those specified in the applet's JNLP file, in particular the width, height, codebase, and code / main-class attributes. The width and height should definitely come from the browser, as those are the values the browser uses to size theh applet. We found that the codebase should only conditionally override what is in the JNLP file, and only if the JNLP file doesn't itself contain an absolute codebase.

Experience writing content with the new JNLP support indicates that the overriding of the main-class attribute with the applet tag's code attribute is a mistake. It prevents certain kinds of content from being authored effectively. For example, if you want to make a JNLP-launched applet that requires the new plug-in, but want to display something in the applet's area if an older version of the plug-in is installed, the best approach would be to have the code attribute point to a tiny applet drawing something like "Click here to download the new Java Plug-In". Ideally you would like to be able to have one such class on your web server as opposed to needing for each different JNLP launched applet being instantiated on the web pages. If the code attribute didn't override the main-class attribute, you'd be able to write

  <applet code="RequiresNewPlugInApplet" jnlp_href="JNLPLaunchedApplet1.jnlp"></applet>
  <applet code="RequiresNewPlugInApplet" jnlp_href="JNLPLaunchedApplet2.jnlp"></applet>

but with the current code you'd need to write

  <applet code="JNLPApplet1MainClass" jnlp_href="JNLPLaunchedApplet1.jnlp"></applet>
  <applet code="JNLPApplet2MainClass" jnlp_href="JNLPLaunchedApplet2.jnlp"></applet>

and either have a bunch of these backward-compatibility classes on the server or have a one or more jars referenced in the archive tag containing them.

There are other ways to detect whether the JNLP applet was successfully loaded involving calling from JavaScript to Java, but they would block the browser for a long period of time.

SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6667020.0 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6667020

EVALUATION Made the JNLP2Manager ignore any old-style specification of the code attribute, and instead always pick it up from the main-class attribute of the JNLP file.