martinrb at google.com
Sat May 15 05:59:26 UTC 2010
On Fri, May 14, 2010 at 19:24, Xueming Shen <xueming.shen at oracle.com> wrote:
> 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;
> go ZipInputStream
If the input zip file is actually a ZIP64 file for some other reason
(for example to get >64k entries), then ZipInputStream
will still succeed, while ZipFile will probably fail,
in which case the fallback algorithm might be more robust.
But I am happy with any action on your part,
including doing nothing.
>> If the JDK has ZIP64 support,
>> what goes wrong?
> Nothing goes wrong with ZIP64, but we don't have that in 6u (yet)
Oh, right. And a backport of ZIP64 support probably isn't
worth the risk and effort.
>> On Fri, May 14, 2010 at 16:18, Xueming Shen <xueming.shen at oracle.com>
>>> It appears the backport to 6u of the optimization we did in #6332094
>>> 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
>>> so the sequential reading in jar's
>>> old implementation just works "fine" with the >4G zip. But the
>>> 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