United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6667020 Code parameter in applet tag should not override main-class for JNLP launched applets
JDK-6667020 : Code parameter in applet tag should not override main-class for JNLP launched applets

Details
Type:
Bug
Submit Date:
2008-02-23
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-05-28
Component:
deploy
OS:
generic
Sub-Component:
plugin
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b21)

Related Reports
Relates:

Sub Tasks

Description
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.

                                    

Comments
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
                                     
2008-03-05
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.
                                     
2008-03-05



Hardware and Software, Engineered to Work Together