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

[Alexander Zuev]

Sherman et all,

   self-correction regarding the flags, i misread the specification so
flags are: always support UTF-8 file encoding (bit 11) and using EOS
marker for the compressed files(bit 4).

/Alex

On 1/15/14 18:26, Alexander Zuev wrote:
> 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
>>
>