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

[Alexander Zuev]

Hi Sherman,

   Thanks for comments, here are some answers:

   the answer to (1)-(3) is that i do whatever the 
JarOutputStream/ZipOutputStream
of the current JDK does and for a reason - there was a request from 
couple of customers
to make native unpack200 results binary identical to the results taken 
from Java
version. The bits set in the general flags are "reserved by PKWARE" or 
"Currently unused"
according to the Zip specification but ZipOutputStream sets them this 
way. Same goes to the
extraction of crc/size/csize into separate header - just to be 
compatible with Java
implementation.

We indeed do not support large (>4GB) files due to the limitations of 
in-memory
unpacking so yes, i omitted the logic of creation of the extended Zip64 LOC
and CEN entries because there will be no case when they might be called 
upon.
The only Zip64 feature is the support of the archives with >64K files - the
rest id the Java JarOutputStream compatibility tweaks.

   At this moment i don't think that supporting old JDK behavior for the 
jars
with >64K files is required - the older unpack200 wouldn't handle the 
situation
correctly anyways. If the request for such option will emerge then 
implementing
it will be a whole new task.

/Alex

On 1/15/14 8:58, Xueming Shen wrote:
> 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
>