JDK-6449504 : REGRESSION:ZipException exception throws when try to read a XML file
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-07-17
  • Updated: 2017-05-19
  • Resolved: 2006-08-23
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 b97Fixed
Related Reports
Duplicate :  
JDK-6456667 - FileNotFoundException closes all InputStreams for a specific jar file
Relates :  
JDK-6212146 - URLConnection.connect() fails on JAR Entry it creates file handler leak
Description
J2SE Version (please include all output from java -version flag): 
 1.6.0-rc-b91

Does this problem occur on J2SE 1.4.x or 5.0.x ?  
  No, and does not happen in 1.6.0-rc-b76 

Operating System Configuration Information (be specific): 
  XP + SP2

Hardware Configuration Information (be specific): 
  Pentium 4, 3.00 GHz, 504 MB RAM.

Bug Description:
 Moved to the latest build (91) after working with build 76 and application stopped working: 
 It throws the following exception while trying to read a XML file:

java.util.zip.ZipException: ZipFile closed
	at java.util.zip.ZipFile.ensureOpenOrZipException(Unknown Source)
	at java.util.zip.ZipFile.access$1100(Unknown Source)
	at java.util.zip.ZipFile$ZipFileInputStream.read(Unknown Source)
	at java.util.zip.ZipFile$ZipFileInputStream.read(Unknown Source)
	at java.io.FilterInputStream.read(Unknown Source)
	at org.apache.xerces.impl.XMLEntityManager$RewindableInputStream.read(Unknown Source)
	at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
	at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
	at com.mercury.ftjadin.utils.xmlParsing.DomParserFactory.run(DomParserFactory.java:112) 


Steps to Reproduce (be specific):
  It happens when calling org.apache.xerces.parsers.DOMParser.parse for a XML
  file that is in a jar within the class path.
a sample application reproducing the bug had been added into the bug report.
The application works correctly on build 76 but fails on 91.
To use it, extract the attached zip, to c:\temp (you must use this hardcoded folder).
Then run the file c:\temp\mustandBug\run.bat
Comments
EVALUATION The problem is the fix for 6212146 is closing the jar file whenever it finds a JarURLConnection that points to a non-existing entry. It should only do this when jar file caching is disabled. Here is a minimised test case. Needs a jar file with one entry called /test.txt public class JarTest { public static void main (String[] args) throws Exception { URL url = new URL ("jar:file:foo.jar!/DoesNotExist.txt"); JarURLConnection j1 = (JarURLConnection)url.openConnection(); URL url2 = new URL ("jar:file:foo.jar!/test.txt"); JarURLConnection j2 = (JarURLConnection)url2.openConnection(); try { j2.connect (); } catch (IOException e) { System.out.println ("Got exception from j2; BAD"); } try { InputStream is = j1.getInputStream (); } catch (IOException e) { System.out.println ("Got expected exception from j1 "); } try { InputStream is = j2.getInputStream (); readAndClose (is); System.out.println ("OK"); } catch (IOException e) { System.out.println ("Got unexpected exception from j2"); } } static void readAndClose (InputStream is) throws IOException { while (is.read() != -1) ; is.close(); } }
08-08-2006
EVALUATION This appears to be due the fix for 6212146. I modified ZipFile.java to see opens and closes of ZipFiles, and found that sun.net.www.protocol.jar.URLJarFile.close is invoking ZipFile.close on an already-closed ZipFile. The attached logjz06.txt shows the debug output and stack trace. (The exception "who caused this" was thrown from ZipFile.close when an already-closed ZipFile was again closed.) This regression does not occur in b77, but does in b78. URLJarFile.java was changed in b78. Undoing the change prevents this bug from occurring, hence the fix to 6212146 seems to have caused the regression.
04-08-2006
EVALUATION I have taken the sample application provided and modified the run.bat script to use -verbose:class in the java command. I am attaching the results (log) which show that no jaxp package names of com.sun.org.apache are being used. I am changing the bug's category to hopefully find a more suitable fit based on the exception which is thrown.
01-08-2006
EVALUATION note that this is not a JAXP bug, the calling trace is all Apache into J2S2. the JAXP team will try and take a look at what is happening if a reproducible test case is provided.
25-07-2006
EVALUATION note that user reported error is not using Sun software. JAXP has package names of com.sun.org.apache.xerces.internal. Apache versions of JAXP are being used in this CR. some possible things that may be happening: - user software is explicitly loading an Apache class v. using JAXP's Factory mechanisms - user has Apache jars in endorsed dirs or bootclasspath with a META-INF entry that prefers Apache classes one way to demonstate this would be to: java -verbose:class and examine the output for classloading locations. the classes will not be coming from Mustang.
17-07-2006