We have a fairly complex signed applet that's been working fine for us since we developed it a couple of years ago. It runs fine with Java 1.5 and 1.6 on all OS/browser configurations we care about.
It does not work with Java 1.7 in any browser on Windows 7 or Vista. We've seen it work on Windows XP. This applet is running in sites that are served by Apache connecting to Tomcat 6 using mod_proxy.
That's all for background information, as I have reduced the problem down to a very simple, unsigned applet:
package myapplet;
import java.applet.Applet;
import java.awt.Color;
import java.awt.Graphics;
public class MyApplet extends Applet {
private static final long serialVersionUID = 1L;
public void paint(Graphics g) {
g.drawRect(0, 0, 250, 100);
g.setColor(Color.blue);
g.drawString("Look at me, I'm a Java Applet!", 10, 50);
}
}
If this applet class is put into a jar file with another file that takes the total (compressed) size of the jar file over about 18KB then the applet doesn't load when served by Tomcat 6 (or Apache 2.2) running locally.
I played around by adding a text file to the jar file and changing the size of the text file. I got it to the point where it would go from working to not working by adding one character to the text file.
Looking at the console log with trace on it is hanging at the point where it is trying to download the jar file. Here's the thread that I think is hanging:
"thread applet-com.bright.assetbank.clientsideedit.myapplet.MyApplet-1" prio=4 tid=0x048d8c00 nid=0x19b8 runnable [0x0700d000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
- locked <0x29fd75b0> (a java.io.BufferedInputStream)
at sun.net.www.MeteredStream.read(Unknown Source)
- locked <0x29fd75d0> (a sun.net.www.http.KeepAliveStream)
at java.io.FilterInputStream.read(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
- locked <0x29fd7630> (a java.io.BufferedInputStream)
at java.io.FilterInputStream.read(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.downloadJAR(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.access$000(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source)
at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source)
- locked <0x29f2a938> (a sun.plugin.net.protocol.jar.CachedJarURLConnection)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
- locked <0x29f2a938> (a sun.plugin.net.protocol.jar.CachedJarURLConnection)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
- locked <0x29dc7e98> (a com.sun.deploy.security.DeployURLClassPath)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
- locked <0x29dc7ed8> (a sun.plugin2.applet.Applet2ClassLoader)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
- locked <0x29dc7f78> (a sun.plugin2.applet.Applet2ClassLoader)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
- locked <0x29dc7f78> (a sun.plugin2.applet.Applet2ClassLoader)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Here are the last 4 lines in the Java console:
network: Cache entry not found [url: http://localhost/editor.jar, version: null]
network: Connecting http://localhost/editor.jar with proxy=DIRECT
network: Connecting http://localhost:80/ with proxy=DIRECT
network: Connecting http://localhost/editor.jar with cookie "csrftoken=523154b2e73a76b6f2088464bd4df4f7"
Some additional information:
Has anyone else seen this behaviour when trying to load an applet with Java 7 running in a browser on Windows 7 or Vista? Is there a solution?
Step-by-step instructions for how to reproduce this problem:
For example:
<html>
<body>
<applet code="myapplet.MyApplet" name="MyApplet" width="300" height="300" archive= "editor.jar" ></applet>
</body>
</html>
The workaround for bug 7183450 in the Java bug database fixes this issue, which is to add
-Djava.net.preferIPv4Stack=true
to the JVM arguments.
For example, to get my test applet running (see the example in my question above):
<html>
<body>
<applet code="myapplet.MyApplet" name="MyApplet" width="300" height="300" archive= "editor.jar" >
<param name="java_arguments" value="-Djava.net.preferIPv4Stack=true">
</applet>
</body>
</html>
This is probably because the remote servers hosting our applet currently don't let IPv6 comms through their firewalls.
Interestingly, some of our Windows 7 machines still didn't work even with this workaround when running Java 1.7_05 but then did work (with this workaround) when upgraded to Java 1.7_06 (which is now available).