The applet viewer worked earlier in the Jaunty cycle. I was using it successfully (on amd64 architecture) and then it stopped working - unfortunately when I first noticed it I'd not used a Java applet for a couple of weeks so couldn't pin it down to the package update that caused the issue.

Looking at the changelog indicates a major change in:

openjdk-6 (6b14-1.4.1-0ubuntu1) jaunty; urgency=low

  * Update IcedTea to the 1.4.1 release.


Looking at the IcedTea commits for the 1.4.1 release shows some relevant additions:

http://icedtea.classpath.org/hg/release/icedtea6-1.4.1/rev/b7957dd8ce9a

After reading the changelog and diffs the likely culprit is:

+ * IcedTeaPlugin.cc: Supply cookie info to Java side.
+ * plugin/icedtea/sun/applet/PluginAppletViewer.java: Apply patch from
+ Xerxes RÃ¥nby to prevent initialization timeout on slower systems. Also,
+ use cookie info when equests for jar are made. 

Moving on to debugging the applet viewer, the debug trace for the test sites shows:

ICEDTEAPLUGIN_DEBUG=1 firefox http://java.com/en/download/help/testvm.xml
...
IcedTeaPluginInstance::SetWindow: Instance 0x2ac18f0 waiting for initialization...
...
REQUEST TAG, PARSING Thread[Thread-1,5,main]
... *** waits and CPU usage headlines ***
Initialization for instance 1 has timed out. Marking it void
ICEDTEA PLUGIN: Instance::SetWindow return

Looking at the source of "REQUEST TAG, PARSING..." at plugin/icedtea/sun/applet/PluginAppletViewer.java:386:PluginAppletViewer::handleMessage()

	 PluginDebug.debug ("REQUEST TAG, PARSING " + Thread.currentThread());
	 PluginAppletViewer.parse( identifier, request.handle,
			 new StringReader(request.tag),
			 new URL(request.documentbase) );


The IcedTea diff for the PluginAppletViewer::parse() function shows the diff:

http://icedtea.classpath.org/hg/release/icedtea6-1.4.1/diff/b7957dd8ce9a/plugin/icedtea/sun/applet/PluginAppletViewer.java

@@ -1455,6 +1467,11 @@ import sun.misc.Ref;
public static void parse(int identifier, long handle, Reader in, URL url)
throws IOException {
+
+ // wait until cookie is set (even if cookie is null, it needs to be
+ // "set" to that first
+ while (!siteCookies.containsKey(identifier));
+ 

My suspicion is that this the CPU us spinning on this while() condition because the HashMap never contains the 'identifier' key.

Looking further, the only place where (even a null cookie) is set is in handleMessage() when it receives a "cookie" message:

             } else if (message.startsWith("cookie")) {
                 
                 int cookieStrIndex = message.indexOf(" ");
                 String cookieStr = null;

                 if (cookieStrIndex > 0)
                     cookieStr = message.substring(cookieStrIndex);

                 // Always set the cookie -- even if it is null
                 siteCookies.put(identifier, cookieStr);
             }

However the debug trace doesn't show any "PAV handling" for a "cookie" - only "handle" and "tag".

Looking further at the IcedTea commits shows that the cookie handling was omitted from the original commits:

http://icedtea.classpath.org/hg/release/icedtea6-1.4.1/rev/546ef0cdee06

 2009-03-09 Lillian Angel <email address hidden>

  * IcedTeaPlugin.cc: Merged from icedtea6 properly. 

Which includes in part:

+ nsCString cookieInfo(instanceIdentifierPrefix);
+ cookieInfo += "cookie ";
+
+ char* cookieString;
+ if (GetCookie(documentbase, &cookieString) == NS_OK)
+ {
+ cookieInfo += cookieString;
+ }
+
+ factory->SendMessageToAppletViewer (cookieInfo);
+ factory->SendMessageToAppletViewer (encodedAppletTag);