This is an upstream report based on Ubuntu Bug LP #199732 https://bugs.launchpad.net/ubuntu/+bug/199732 == Overview == Loading some Java applets via Firefox and the plugin with openjdk-6 results in: Exception in thread "main" java.lang.NullPointerException at sun.applet.PluginMain.start(PluginMain.java:211) at sun.applet.PluginMain.main(PluginMain.java:73) See, for example: http://www.jeacle.ie/mortgage/ca/ http://wypte.acislive.com/pda/pda_maps.asp?SysId=30 I'll detail the analysis and the fix after this explanation. == Background == There are an unknown number of Internet sites hosting Java applets that fail when using the icedtea plug-in but work using the Sun Java plug-in. The reason for the failure is usually a result of the historic mess that was made of the HTML EMBED, APPLET, and OBJECT tags. As a result of the various contrived work-arounds that web-site authors used to try and ensure that all browsers managed to load a Java applet, there are many combinations of these tags and the PARAM name/value attribute tags that attempt to use browser quirks to ensure the user does see the Java applet. There has never been a standard for the EMBED tag particularly, it having grown over time from its beginnings in Netscape Navigator. There have likewise been various unofficial extensions to the OBJECT tag - the only properly standardised tag - which should really replace the other two tags in modern browsers and web-applications. As a result users often suffer, caught between a rock and a hard place when things go wrong - such as this NullPointerException - since they have no influence over the web-site operators in most cases, and often get told by developers that it is the web-site's problem, not the plug-in, despite the widespread use of varying combinations of browser-specific tag combinations. (See, for example, the responses in Bug #151). == The Issue == In the cases I've dealt with the failures are caused by the use of the EMBED tag with no "code" attribute. However, the HTML author has attempted to ensure all browsers/Java plug-ins load the applet by including OBJECT and/or APPLET variations as well as using PARAM name/value pairs. The plug-in currently refuses to accept a tag-set passed by the browser plug-in *before it has been completely parsed* if the initial tag isn't of the form: ... It will also then ignore any PARAM name/value pairs as being "outside an APPLET tag". This is unfortunate since in many cases the PARAM pairs contain values that the plug-in can use to load the applet successfully. == The Solution == The patch I've created refines the way PluginAppletViewer.parse() deals with the EMBED tag. It adopts the same logic as is already present for the OBJECT tag, deferring rejection of the attributes until the closing tag, and thus allowing any PARAM name/value pairs after the opening tag to be parsed into the attributes Hash. When the closing EMBED tag is parsed, if there is still no "code" or "object" attribute, the patch makes one last attempt to locate the entry-point class. It first looks for the attribute "classid". If it is found, the patch further checks that the value is prefixed "java:". If so, a new "code" attribute is created and assigned the remaining characters of the "classid" value. This will allow the applet to start. E.g. If any of these attempts fail it nullifies the attributes hash and fails with the same message as previously. This patch allows the plug-in to work with many more combinations of OBJECT, APPLET, and EMBED tags and improves the user experience and perception of openjdk and icedtea. == Exception Analysis == This bug is caused when the Java plug-in hasn't had a window registered using PluginMain.registerWindow(), which will set PluginMain.currentWindow. Without PluginMain.currentWindow set (it is initialised to null), when the gcjwebplugin sends the applet the "width" message, the applet's PluginMain.start() message-reading loop reads the width correctly, but then tries to get the internal height property using: int height = currentWindow.getHeight(); Because currentWindow is NULL it causes the Null Pointer Exception on line 211. The problem is caused in PluginAppletViewer.parse(...). There are several overloaded versions of this function but they all pass through to the work-horse overload that takes a complete set of arguments. In PluginAppletViewer.parse() it scans the HTML APPLET/OBJECT/EMBED tag and extracts the attribute values. When it finds an EMBED tag it passes it to PluginAppletViewer.scanTag(). That method is responsible for scanning the attributes inside the EMBED tag and assigning them to the attributes Hash. When scanTag() returns the EMBED detection-logic does some sanity checks on the attributes to ensure it has what it needs to execute the applet successfully. It checks for the CODE, WIDTH, and HEIGHT attributes not being null. If any one of them is null it sets the attribute reference to null too - effectively wiping them all out. When the logic in PluginAppletViewer.parse() finds the closing tag it checks if the attributes reference IS NOT null and if so calls PluginAppletViewerFactory.createAppletViewer(). That in turn calls PluginMain.registerWindow() which, as I said at the beginning, sets PluginMain.currentWindow. But, because an attribute of the EMBED tag was missing, the attribute Hash reference was null and so PluginMain.registerWindow() wasn't called and PluginMain.currentWindow remained with its initialised value, which is null. Hence the bug. In the case of the sites here the missing attribute is "code", and you can see the warning in the output: Warning: tag requires code attribute. That really should say "Error" since it is fatal. Because the EMBED tag was not part of a W3C standard the definition of legal parameters is hazy. It has been introduced for HTML 5 *but* will not support the CODE attribute. == Patch == Currently the patch is included in a provisional Ubuntu openjdk-6 source package as debian/patches/plugin-embed-use-param-translate-classid-to-code.patch It would be preferable to have it included upstream since other distributions have bugs reported for the same issue. The patch could easily be moved to ./patches/ in the openjdk-6 source package, as long as it is applied after patches/icedtea-plugin.patch