JDK-6189491 : Silent failure of corrupt Jar/Zip files during classloading yields poor diagnosability.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.1_12
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: generic
  • Submitted: 2004-11-02
  • Updated: 2012-10-08
  • Resolved: 2005-04-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b23Fixed
Related Reports
Relates :  
JDK-6189465 - More error detail when encountering problems reading Zip files.
Relates :  
JDK-6239036 - (cl) classLoader must be able to provide better diagnostics when encountering a malformed JAR
Relates :  
JDK-6190121 - Jar is not usable for testing integrity of Jar files.
Description
We have a corrupt jar file containing (in this case) SAX classes.  
The classes fail to load with no warning that we are traversing a corrupt Jar file in our classpath:

(5.9)$ java -classpath ./saxorig.jar:.  Test
java.lang.ClassNotFoundException: org.xml.sax.Parser

-verbose:class does not list saxorig.jar at all: this was the only clue that it was a corrupt jar/zip file.

Using 1.3.1, the output is as above: ClassNotFoundException.  In 1.4.2 and 1.5, the SAX classes are found in rt.jar (ie. class is found, but the _wrong_ class is found: the jar file prefixed in our bootclasspath is ignored).  

The original problem was with 1.3.1 and applets in the plugin, but appears to be common to all versions including 1.5: a corrupt Jar file is simply ignored with no warning.

(The fact that this genuine "found in the wild" corrupt jar/zip file contains classes which are now in rt.jar rather spoils the testcase a little when run in 1.4.2/1.5.)
###@###.### 11/2/04 16:02 GMT



###@###.### 2005-1-25 19:49:35 GMT
Comments
EVALUATION The problem here is that the Central Directory of the ZIP file does not exist, therefore the JAR file is corrupt and the desciption is right, there is no check in the VM classloading code to catch this error and the VM continues. This is a bad thing, when a JAR could not be loaded in the bootclasspath, the VM should abort gracefully by throwing an Exception, this may not be possible since the VM is not fully initialized to do so, specifically if the JAR in question is being loaded even before rt.jar. In summary the VM should abort gracefully under these conditions. ###@###.### 2005-1-20 21:48:18 GMT This bug addresses the VM not failing if a corrupt JAR exists in the BootClassPath. ###@###.### 2005-1-25 19:49:35 GMT A seperate bug for the System ClassLoader is submitted, BugId: 6239036 ###@###.### 2005-03-10 20:10:46 GMT
02-11-2004