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

[Xueming Shen]

Thanks for the review. webrev has been updated accordingly. Do CCC next 
week.

-Sherman

Martin Buchholz wrote:
> On Fri, May 14, 2010 at 23:53, Xueming Shen <xueming.shen at oracle.com> wrote:
>   
>> OK, Thanks!
>>
>> btw, did you ask this before?
>>
>> http://cr.openjdk.java.net/~sherman/6581715/webrev/
>>     
>
> I think I did.  All JDK classes returning an Enumeration
> should be retrofitted to implement Iterable.
>
> Looks good.
>
> ---
>
> There are a few more places where you can remove
> ZipFile.this.
>
>  507                                    ",\n jzfile = " + ZipFile.this.jzfile +
>  508                                    ",\n total = " + ZipFile.this.total +
>  509                                    ",\n name = " + ZipFile.this.name +
>
>
> Martin
>
>   
>> -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
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>         
>>