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.
                                     

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