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

Alexander Zuev alexander.zuev at oracle.com
Wed Jan 15 14:26:34 UTC 2014

Hi Sherman,

   Thanks for comments, here are some answers:

   the answer to (1)-(3) is that i do whatever the 
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

We indeed do not support large (>4GB) files due to the limitations of 
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 
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 
with >64K files is required - the older unpack200 wouldn't handle the 
correctly anyways. If the request for such option will emerge then 
it will be a whole new task.


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

More information about the core-libs-dev mailing list