Java Plug-in 1.4.0 throws an IllegalStateException: zip file closed

Question

Cross-posting to reach a wider audience:
Java Plug-in 1.4.0 throws an IllegalStateException: zip file closed
Author: remyb Jul 23, 2002 6:36 AM
A IllegalStateException is thrown when the class loader
try to load a class from my applet JAR file.
The applet is embedded in a JSP page which use the Plug-In 1.4.0.
That JSP is hosted by Tomcat 4.0.1.
The applet JAR file is signed with a self-signed certificate.
The applet has been compiled with JDK 1.4.0.
The jar has been put in the Plug-in cache successfully.
Here is the stack trace I got in the Java Console ...
java.lang.IllegalStateException: zip file closed
at java.util.zip.ZipFile.getEntry(Unknown Source)
at java.util.jar.JarFile.getEntry(Unknown Source)
at sun.plugin.cache.CachedJarFile.getEntry(Unknown Source)
at java.util.jar.JarFile.getJarEntry(Unknown Source)
at sun.misc.URLClassPath$JarLoader.getResource(Unknown Source)
at sun.misc.URLClassPath.getResource(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
Please somebody help me !!
Thanks !
Re: Java Plug-in 1.4.0 throws an IllegalStateException: zip file closed
Author: mutmansky
In Reply To: Java Plug-in 1.4.0 throws an IllegalStateException: zip file closed Jul 26, 2002 6:36 AM
Reply 1 of 1
I've got a very similar error, but unfortuneatly I don't have an answer yet. The only difference is that my Applet is embedded in a standard HTML page, and loaded via Apache. Once the Applet runs, it then communicates with the servlet via Tomcat. I also exchange data with another server task via CORBA.
But everything else is the same, self-signed applet, applet compiles successfully, and jar is being put in the Plug-in Caceh successfully.
I have narrowed the problem down a bit, and maybe you can tell me if you're in a similar situation:
In my case, I need to encrypt the data that I'm sending through CORBA, so I create a Cipher object using Cipher.getInstance(). This method call seems to be the catalyst of my troubles. No matter where I move that call in my code, the next time the code tries to instantiate a class defined in my applet jar file after that "getInstance" call, I get the "zip file closed error." It's like the classloader is confused, because the Cipher.getInstance method would be accessing a different jar file or something. Are you trying to do something similar? Maybe not creating a Cipher, but creating some other object defined outside your own jar-file?
To top it off, if I disable caching in the Plugin control panel, everything works fine. But that's not really an option for me, since it slows things down a lot, and I can't make all my users go into their control panels and disable caching. But at leasts it makes me confident that there's not a problem with my code.
In my latest attempt to circumvent this problem, I even put the Cipher.getInstance() call in a static initializer. Here's the stack trace from that attempt:
java.lang.IllegalStateException: zip file closed
at java.util.zip.ZipFile.getEntry(Unknown Source)
at java.util.jar.JarFile.getEntry(Unknown Source)
at sun.plugin.cache.CachedJarFile.getEntry(Unknown Source)
at java.util.jar.JarFile.getJarEntry(Unknown Source)
at sun.misc.URLClassPath$JarLoader.getResource(Unknown Source)
at sun.misc.URLClassPath.getResource(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at com.uss.wbi.client.WBIClient.<init>(WBIClient.java:404)
at com.uss.wbi.client.WBIApplet.init(WBIApplet.java:122)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
In other words, since the getInstance method is in a static initializer, the next thing to run is the applet.init(), which is what is failing now. If I move the Cipher.getInstance method into the client constructor, the next time I instantiate a new object, I'll get the error there.
Has anybody else seen anything like this? Or does anybody know how I can flush the Cache from the applet code? Or can I reset the ClassLoader in some way in the code?
Thanks,
Steve

Answer 1

Well, I finally came to a solution that is acceptable at least to me, if not ideal. I've started using the BouncyCastle lightweight API. This makes my code somewhat more complicated, and I had to bundle up all the BouncyCastle classes that I'm using into a jar file, and download that to my applet along with my client jar file (after signing the jar files). Using this Lightweight API bypasses the Cipher.getInstance() method all together, and is a little harder to use, but at least everything is working consistently now.
I still believe this to be a bug either in the ClassLoader or the Cipher.getInstance() method. I intend to try to write a test applet that reproduces the error in a more simple way and if I can pull that off, I'll submit a bug report to Sun.
Thanks to all who responded!!
Steve