Martin Buchholz wrote:
Well, the obvious thing to do is to use ZipFile,
and if something goes wrong,
back off and try the old implementation with
ZipInputStream in addition.
I will add a check like
if (fname != null && new File(fname).length() < 0x100000000L)
go ZipFile;
else
go ZipInputStream
If the JDK has ZIP64 support,
what goes wrong?
Nothing goes wrong with ZIP64, but we don't have that in 6u (yet)
-Sherman
Martin
On Fri, May 14, 2010 at 16:18, Xueming Shen <xueming.s...@oracle.com> wrote:
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.
-Sherman
