JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format.
alexander.zuev at oracle.com
Wed Jan 15 14:34:06 UTC 2014
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).
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
> 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 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
> 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
>> header = ( 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
>> they don't have the choice given the nature of "stream", which means
>> 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
>> extra data descriptor here.
>> (3) to add the "cafe" jar magic is interesting. that is really an old
>> 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.
>> 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
>>> Bug description is: https://bugs.openjdk.java.net/browse/JDK-8029646
More information about the core-libs-dev