RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v5]
Jaikiran Pai
jpai at openjdk.org
Mon Feb 12 10:34:04 UTC 2024
On Fri, 9 Feb 2024 10:41:18 GMT, Eirik Bjørsnøs <eirbjo at openjdk.org> wrote:
>> test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java line 112:
>>
>>> 110: ZipEntry e1 = new ZipEntry("first");
>>> 111: // Make room for an 8-byte ZIP64 extra field
>>> 112: e1.setExtra(createOpaqueExtra((short) Long.BYTES));
>>
>> Hello Eirik, I couldn't understand why we first add a opaque extra field first and then update it to be a zip64 extra field. Why do we do this?
>
>> Hello Eirik, I couldn't understand why we first add a opaque extra field first and then update it to be a zip64 extra field. Why do we do this?
>
> `ZipEntry.setExtra` processes the byte array argument, looking for Zip64 extended fields which it can extract the size fields from. To prevent this parsing from happening, we temporarily use the `unknown` tag.
>
> In this particular case, `ZipExtra.setExtra` actually ends up skipping this processing (because `isLOC == true` and it has a guard for the block size being `>= 16`).
>
> However, I prefer the test to not depend too much on the details of `setExtra` Zip64 processing. This trick is used in other tests as well and may be copied over to a test where the conditions are not the same.
>
> I have refactored a bit and added some code comments to help explain the use of the 'unknown' tag.
>
> Do you think this makes sense?
Hello Eirik, thank you for that detail. Yes, what you note and the updated comment, looks good to me.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/12948#discussion_r1485992196
More information about the core-libs-dev
mailing list