http://javaweb.sfbay.sun.com/~sherman/6332094/

[Xueming Shen]

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.shen at 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
>>
>>