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