-
Bug
-
Resolution: Fixed
-
P4
-
6
-
b46
-
generic
-
generic
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2181427 | OpenJDK6 | Martin Buchholz | P3 | Closed | Fixed | b17 |
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".
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".
- backported by
-
JDK-2181427 "jar t" and "jar x" should use ZipFile, not ZipInputStream
-
- Closed
-
- relates to
-
JDK-4879507 ZipInputStream does not check CRC for stored (uncompressed) files
-
- Closed
-
-
JDK-6280693 Mmap the whole jar files takes too much perceived footprint
-
- Resolved
-