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

[Xueming Shen]

OK, Thanks!

btw, did you ask this before?

http://cr.openjdk.java.net/~sherman/6581715/webrev/

-Sherman

Martin Buchholz wrote:
> 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;
>> else
>>   go ZipInputStream
>>     
>
> Sounds good.
>
> hmmm....
> 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.
>
> Martin
>
>   
>> -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
>>>>
>>>>
>>>>         
>>