JDK-6332094 : "jar t" and "jar x" should use ZipFile, not ZipInputStream
  • Type: Bug
  • Component: tools
  • Sub-Component: jar
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-10-04
  • Updated: 2012-01-13
  • Resolved: 2012-01-13
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 7 Other
7 b46Fixed OpenJDK6Fixed
Related Reports
Relates :  
JDK-6280693 - Mmap the whole jar files takes too much perceived footprint
Relates :  
JDK-4879507 - ZipInputStream does not check CRC for stored (uncompressed) files
Description
jar t using ZipInputStream might be orders of magnitude more expensive
than using ZipFile, because ZipInputStream might have to uncompress each entry.

No longer mmaping the entire zip file makes using ZipFile more reliable.

ZipFile used to have scalability issues if the entire zip file didn't fit into
the address space.
Same applies to "jar x".
Comments
EVALUATION Updated jar.Main to use ZipFile if "files/dirs" specified in extracting (if the whole jar file is getting extracted, there should be no big difference between ZipInputStream or ZipFile, if the whole ZipFile is not mmapped). "t" is to use ZipFile no matter files/dirs specified or not. Good performance boost is observed.
13-01-2009
EVALUATION Using ZipFile instead of ZipInputStream also allows for catching more corruption errors, due to checks in our ZipFile code.
10-10-2006
SUGGESTED FIX Make a versions of extract() and list() that take a filename as an arg instead of an InputStream, make a ZipFile from that filename, and iterate over the entries. The attached Main.java has changes for extract that produced the numbers in the evaluation.
04-10-2005
EVALUATION A quick change to the extract() method sun/tools/jar/Main.java shows a dramatic improvement in extracting rt.jar. The following are approximate averages over 3 runs of "jar xf rt.jar" as reported by /usr/bin/time: 1.5.0_04: real 11.5, user 5.6, sys 5.3 modified: real 7.5, user 5.6, sys 1.6 *** (#1 of 1): [ UNSAVED ] ###@###.###
04-10-2005