JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format.

[Kumar Srinivasan]

Hi Alex,


> Kumar,
>
>   thanks for your findings. See my comments inline.
>
> On 1/15/14 2:10, Kumar Srinivasan wrote:
>> Hi Alex,
>>
>> zip.cpp: (nit) I would keep the hex values to be in upper case just 
>> like the others for
>>               consistency, not a big deal.
>   Fixed.
>>
>>                typo: + // Zip64 END sugnature
>   Also fixed.
>>
>>
>> PackTestZip64.java: shouldn't we test a jar with 64K+  entries ?
>   Do we really have to do so? Creating, repacking, packing, unpacking 
> and comparing of such jar
> file would take a lot of testing time. Right now i'm just testing that 
> we are producing binary
> identical jar after we normalized it. If you think creating of large 
> jar file is necessary i can easily do so.

We must have a test!, it is not necessary that we should execute this 
all the time, but having this
in place, will enable SQ to run this test periodically, and we can run 
it as well during development.
You can copy most of the logic from here, and use the system 
property/strategy to enable the
time consuming one.
http://hg.openjdk.java.net/jdk9/dev/jdk/file/3b4ac8d1b76f/test/tools/launcher/BigJar.java

I think it would be good to test jars created by the JDK (tools.jar or 
some suitable one), using the
golden jar may not be appropriate, since it is a pre-canned binary.

Also I am not sure if we should test jars created by JarOutputStream as 
well as JarFile,
there are some nuances with these APIs and how they write out the jar file.

Kumar

>
> /Alex
>>
>> Kumar
>>
>>
>>
>> On 1/14/2014 10:04 AM, Alexander Zuev wrote:
>>> Please review my fix for
>>>  JDK-8029646: [pack200] should support the new zip64 format.
>>>
>>>   The fix can be found at 
>>> http://cr.openjdk.java.net/~kizune/8029646/webrev.00/
>>>
>>>   Bug description is: https://bugs.openjdk.java.net/browse/JDK-8029646
>>>
>>> /Alex
>>
>