Bug ID: JDK-5105410 ZipFile$ZipFileInputStream doesn't close handle to zipfile

Versions (Unresolved/Resolved/Fixed)

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.

Other	JDK 6
1.4.2_08Fixed	6 betaFixed

The bug seems to be located in the inner class in java.util.zip.ZipFile ? ZipFileInputStream, and more specifically its

public void close()

It doesn?t close its field handle to the ZipFile there and this leaves the file handle leak.

In the customer case the usage of URL.openStream() the customer cannot get access to the zipFile handle and there is no way it can be explicitly closed.

The problem resulting of this effect is that the partner's J2EE is not able to redeploy applications
###@###.### 10/30/04 01:46 GMT

SUGGESTED FIX You can start Kaloyan?s test with this line : java -Xbootclasspath/p:fix.zip FileTest and put the fix.zip(it contains a fixed version of the inner class) in the working dir. The customer provided already a suggestion to fix the problem. See fix.zip in the attachment. You can start the test with this line : java -Xbootclasspath/p:fix.zip FileTest and put the fix.zip(it contains a fixed version of the inner class) in the working dir. You can see the changed lines in close() and close1() in the ZipFileInputStream. Close1() is privately used from the other methods of ZipFile, while close() is left only for explicit calls.

30-09-2004

EVALUATION This sounds like it's the same problem as described in 5072161: OutOfMemoryError while using GZIPOutputStream, zlib memleak 5092131: using 1 MB pagesize throws "not enough space" error with 32bit JVM the submitter has not provided enough information to determine whether it's the same problem. The description in those bugs may enable the submitter to find a good workaround. We need a small program demonstrating the problem. The suggested fix looks incorrect. If two inputstreams are opened to read from two different entries in the same zipfile, then the zip file should not be closed when one of the inputstreams is closed. Looks like Not Our Bug. ###@###.### 2004-09-24 ###@###.### writes: "At first sight, it looks like it might be a problem with JarURLConnection. The problem is that JarURLConnection opens a JarFile object and then returns an InputStream acquired from the JarFile. Closing this stream cannot close the enclosing JarFile because the JarFile does not know if more entries will be requested from it. I think JarURLConnection should wrap its own stream type around the inputstream acquired from the jarfile, and this object can take care of closing the jarfile. This should be straightforward because one JarURLConnection can only be used to access one Jar entry. Then you would not depend on closing the jarfile explicitly from the app, or on the finalizer being called. This is a pretty sensitive area so we would need to check this out thoroughly to make sure it's right." I (Martin) agree with this assessment, although I have not thoroughly investigated it. I don't think there's anything that code in java.util.{jar,zip} can do to fix it. Reassigning this bug to classes_net. ###@###.### 10/30/04 01:46 GMT

30-10-0004

Duplicate :	JDK-6962459 - Can' t delete zip files accessed with jar protocol
Duplicate :	JDK-6175450 - 12 javax/imageio tests are failing with package based installation of JDK on solaris10 sparc
Relates :	JDK-5072161 - OutOfMemoryError while using GZIPOutputStream
Relates :	JDK-4797189 - Finalizers not called promptly enough