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:
- On Windows Vista running Java 7 in a browser our main applet (served by Apache->mod_proxy->tomcat) loads if I uncheck “Enable blacklist revocation check”. It doesn’t load if this is checked. Unchecking this has no effect (i.e. doesn’t make it work) on Windows 7.
- I tried hosting my test applet in Tomcat (locally), Apache (locally) and Apache (on a remote server I access via the Internet). For each one there was a size of jar file above which the applet would not load – however, this size varied between the web servers. For example, on the the remote server the jar file could be much larger – it had to be over ~1MB before it wouldn’t load.
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:
- Copy the code above into a file called MyApplet.java located in a
directory called myapplet - Compile the code, i.e. javac MyApplet.java
- Create a jar file: cd to the parent directory of myapplet and type jar -cvf editor.jar myapplet
- Create a simple HTML page to show the applet.
For example:
<html>
<body>
<applet code="myapplet.MyApplet" name="MyApplet" width="300" height="300" archive= "editor.jar" ></applet>
</body>
</html>
- Put this HTML file and the jar file into the same directory and serve from a web server e.g. Apache or Tomcat.
- Visit this HTML page in Chrome or IE on a Windows 7 OS. The applet will load fine!
- Repeat the above steps, but this time put a small file e.g. an image (e.g. <2KB) into the myapplet directory (next to MyApplet.class) before you create the jar file. This should also work.
- Repeat, but this time put a large image (e.g. >100KB) into the myapplet directory (next to MyApplet.class) before you create the jar file. The jar file will now be quite big. This won’t work, i.e. the applet won’t load. If it does, and you are using Windows 7, then please let me know. While testing, don’t forget that applets are cached so press the x key in the java console to refresh the classloader cache and f5 to refresh the browser.
The workaround for bug 7183450 in the Java bug database fixes this issue, which is to add
to the JVM arguments.
For example, to get my test applet running (see the example in my question above):
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).