JDK-6423026 : Java.util.zip doesn't allow more than 2036 zip files to be concurrently open on Windows
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2006-05-08
  • Updated: 2011-02-16
  • Resolved: 2006-07-01
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
5.0u15Fixed 6 b91Fixed
Related Reports
Relates :  
JDK-6374379 - ZipFile class cannot open zip files with long filenames
Relates :  
JDK-4189011 - java.io: Cannot open more than 2035 files (win32)
Relates :  
JDK-2141066 - ZipFile class cannot open zip files with long filenames
Relates :  
JDK-4519027 - Zip file names should support Unicode on NT
Relates :  
JDK-6474389 - test/java/util/zip/ZipFile/ManyZipFiles.java should clean up after itself
Description
In JDK 1.5.0_06, it is currently not possible
on Windows (x86 & X64) to have more than 2.048 different zip files
concurrently open. The problem doesn't occur on Solaris & Linux

     However this is not a windows limitation as a Win32 program which does the same  operation using CreateFile doesn't have this problem.  Instead  this is a limitation built into the C library file handling.  

Please find enclosed a sample  program (filehandleshortage.java).

you will receive an output similar to the following. The program created and then tries to open 2.100 zip files and read from them (see also the comment in the source file).
Test failed, exception occured. Opened 2036 files

java.util.zip.ZipException: Too many open files
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(Unknown Source)
        at java.util.zip.ZipFile.<init>(Unknown Source)
        at FileHandleShortage.doTest(FileHandleShortage.java:52)
        at FileHandleShortage.main(FileHandleShortage.java:27)

The Fix for the bug 4189011 seems to resolve this same problem for java.io.File. Similar Fix needs to be done for java.util.zip.ZipFile
Comments
SUGGESTED FIX Change the zip C code to use handles or file descriptors, depending on platform.
10-05-2006
EVALUATION ZIP_Open (ZIP_Generic_Open) call JVM_Open which calls hpi::open and hpi::open mapped to C library function open. On Windows, there is a limitation of 2048 open file handle in the implementation of MSVCRT. See bug 4189011, java.io used to use open, now this bug fixed in tiger, use native Windows API on windows. If we still want to use hpi library, could we consider a restructure of it? One place fix could save alot efforts fixing in many places. Another choice could be giving up hpi usage in hotspot. There are four types in hpi interface: file, socket, library, and system. Those functions in those interface can be implemented based on platforms in hotspot thus hpi could be removed forever.
08-05-2006
EVALUATION To fully resolve issues like this, we need to use common infrastructure at the C level consistently. It is very hard to do this for all places where C code needs to open files, especially during JVM startup. We cannot use the seductively named JVM_Open; it simply isn't completely reliable on Windows.
08-05-2006