RFR: JDK-8073158 zip files with total entry count 0xFFFF need not be ZIP64 files

[Kumar Srinivasan]

Hi Martin,

In case you have missed it, jdk/test/tools/launcher/BigJar.java
has a suppressed large file test, you might want to enable it
if not already done, I think this test originally came from google
not sure, nevertheless,  a similar one also exists in:
langtools/test/tools/javac/file/zip/T6836682.java

As for the changes I glosssed over it, yea it is scary, but thanks for 
making
the changes.

> The Right Thing is to have only one C Zip implementation, shared by
> launcher, zip_util, and pack200.  And my change is one step towards that,
> but I'm not tackling the big job right now.
+1.



Kumar
>
> On Wed, Mar 25, 2015 at 10:55 AM, Xueming Shen <xueming.shen at oracle.com>
> wrote:
>
>> It looks fine...I hope you guys also have some tests over there to bring
>> in more confidence :-)
>>
>> It might be "easier" to simply update the original haveZIP64() with the
>> code
>> we have in zip_util.c in which we also try to read the end64 to verify if
>> we
>> really have one. Your choice though.
>>
>> -Sherman
>>
>>
>> On 03/25/2015 09:55 AM, Martin Buchholz wrote:
>>
>> Yeah, this review is kinda scary.  There's a lot of technical debt here,
>> and this change only addresses some of it.
>>
>>   A variant of this code is in use at Google.
>>
>> On Mon, Mar 23, 2015 at 1:18 PM, Martin Buchholz <martinrb at google.com>
>> wrote:
>>
>>>   Hi Xueming and Alan,
>>>
>>>   I'd like you to do a code review.
>>>
>>>   https://bugs.openjdk.java.net/browse/JDK-8073158
>>>
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/0xffff-entries-zip-file/
>>>
>>>   Of course, the really correct thing is to have at most one zip
>>> implementation per programming language, but I'm not trying to fix that
>>> here (how many zip implementations does openjdk have?)
>>>
>>
>>