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

[Martin Buchholz]

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
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>