JDK-6722585 : New plugin has very misleading error messages for invalid JNLP files
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows,windows_xp
  • CPU: x86
  • Submitted: 2008-07-04
  • Updated: 2010-09-08
  • Resolved: 2008-07-19
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 b28Fixed
Related Reports
Duplicate :  
Relates :  
If the JNLP used for an applet is invalid then the applet will fail to load. This is correct. However, the error message in the Java console is extremely misleading, causing the developer to search in vain trying to fix the wrong thing.  The plugin will report that the JNLP file could not be found, when in fact it *was* found but it did not parse correctly. This problem has already been seen in the wild by external developers testing JavaSE 6 update 10 betas. 

Below is the stack trace produce if you leave the name, width, or height attributes out of the applet-desc element of your JNLP file:

exception: null.
java.io.FileNotFoundException: JNLP not available: foo.jnlp
   at sun.plugin2.applet.JNLP2Manager.loadJarFiles(Unknown Source)
   at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
   at java.lang.Thread.run(Unknown Source)
Exception: java.io.FileNotFoundException: JNLP not available: foo.jnlp

There are two things wrong here. First, there is an exception being thrown "exception: null" without printing the full stack trace or a description of the real problem. Second, the secondary exception: FileNotFoundException, is incorrect. The jnlp *was* in fact found, but the parsing failed because a required attribute was missing.  The actual failing code should instead be throwing a valid exception, and whatever code is throwing the FNF should check to ensure that the file was in fact not found.

To reproduce this error, take any working JNLP applet and remove the width attribute of the applet-desc tag in the JNLP file.

This error has been found in the community as evidenced by these forum posts:



In the second case, it appears that the XML file was malformed, but again the exception was FileNotFound rather than an XML parsing exception.

EVALUATION New code in Java Web Start in 6u10 for handling relative codebases, which was introduced with the JNLP support in the new Java Plug-In in 6606784, was squelching exceptions during parsing of invalid JNLP files, making it appear as though the file were missing as opposed to malformed. Added explicit checks for the parse exceptions and propagation of these exceptions out of the JNLP parser. All of the calling code in the workspace was already properly handling these potential exceptions even though they weren't declared in the signatures of the methods in question.