xueming.shen at oracle.com
Fri May 14 23:18:47 UTC 2010
It appears the backport to 6u of the optimization we did in #6332094
breaks someone's code.
Obviously the ZipInputStream works fine with >4G zipfile even without
the ZIP64 format support
as long as the individual zip entries inside is smaller than the 4G
limit, so the sequential reading in jar's
old implementation just works "fine" with the >4G zip. But the
optimization we put in to use ZipFile
instead causes the regression because it needs the access to the 64bit
central directory table if the
zip is > 4G. While it is arguable if a > 4G zipfile without the ZIP64
extension table is a "correctly"
formatted zip file or in fact that jar can never create a > 4G zip file
before we added the ZIP64
support, regression is a regression:-(
I believe you also backport the same thing into 6open.
More information about the core-libs-dev