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.