Applet fails to load with Java 1.7 on Windows 7 if jar file is >a certain size
Asked Answered
P

1

13

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.
Pyretic answered 15/8, 2012 at 20:15 Comment(13)
That appears to make it just size-related. What are you downloading from? And can you post the relevant Java Console output here? I have a much larger applet that works correctly with Java 7.Leman
But does your applet work on Windows 7 if you include directories in the main jar file?Pyretic
@EJP: you're right - it's the size of the jar file that matters. I'll update my question.Pyretic
Do you have any anti-virus program on the machines you did your tests? Try deactivating those, and if possible Windows 7/vista's own security stuff as well (UAC, Firewall, etc) and see if it works like that.Smith
Just discovered that if I serve the applet through Apache directly then it loads fine, so the problem seems to be related to using Tomcat (6). Going to update the question accordingly...Pyretic
Try downloading the jar manually and verify it arrives intact. Run a SHA1/MD5 checksum to verify it is unchanged.Reproach
Sorry, I was wrong about it working in Apache - it doesn't. @Devon_C_Miller: the jar doesn't arrive in the 'temporary files' cache, and I think the stack trace above (and the java console logging) shows that the applet is hanging at the point where it is trying to download the jarPyretic
@Martin: We need to eliminate one of the endpoints, and right now it seems like your server/mod_proxy is the problem, not the client. So downloading it using wget or similar (e.g. by just pointing your browser to the URL) and then running a checksum on client and server (and comparing) is a good way to isolate the problem to the client or server.Vergne
They are the same. Let me explain what I did in case it's wrong: a) Learnt about sha1sum ;-) b) Downloaded the jar through my browser by going to localhost/editor.jar c) Ran sha1sum editor.jar in Cygwin on the downloaded file d) Did the same for editor.jar obtained from its location in the Apache directory e) Compared the two outputs - which were identicalPyretic
BTW - note that the problem exists when I eliminate Tomcat and host the jar file in Apache in a simple HTML pagePyretic
Does it behave the same if you run this applet from your browser with a local html file instead of downloading it from a server?Adsorbent
Good question - no, it works fine (suggesting to me that this is about security)Pyretic
Have you tried to distribute your applet as pack200 compressed instead of jar?Lobation
P
2

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).

Pyretic answered 15/8, 2012 at 20:15 Comment(1)
Yes, this help. You rescue my live. Many thanks for this tip.Goutweed

© 2022 - 2024 — McMap. All rights reserved.