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

[Xueming Shen]

Hi Alex,

(1) what's the bits are you setting into the general flags fields as below?

      header[4] = ( store ) ? SWAP_BYTES(0x0800) : 0x0808;

(2) why do you want to use extra data descriptor to set crc/size/csize?
while I understand that Jar/ZipOutputStream does that, but that is because
they don't have the choice given the nature of "stream", which means they
don't know the csize and crc value until all bits get compressed/crc-ed. In
case of unpack, all bits should have already be compressed and the crc value
has been calculated, I don't see any compelling reason we need to sue the
extra data descriptor here.

(3) to add the "cafe" jar magic is interesting. that is really an old 
implementation
details of "jar on solaris". any request to add this one into the unpack 
tool?

(4) I dont think the changeset is tryin to support ZIP64 extra fields tag in
LOC and CEN tables (I kinda understand why, given the unpack does all
"unpacking" work in memory, it is practically unrealistic to have a >4G
memory to hold all > 4G data). It appears most of the changes other than the
zip64 end table is really not related to "support the new zip64 format"

(5) flag "jdk.util.zip.inhibitZip64" is introduced in jdk8 to support a 
"old"
behavior for > 64K total entries. You guys might want to consider if it is
also worth considering to have this flag supported in unpack200.

-Sherman

On 1/14/14 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