On Thu, 8 Feb 2024 14:09:35 GMT, Eirik Bjørsnøs <eir...@openjdk.org> wrote:
>> Please review this PR which suggests we speed up the `Zip64SizeTest` using a >> small-sized ZIP64 ZIP file specifically created to reproduce the issue being >> tested. >> >> The disk space requirement of this test is known to cause problems in some >> builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866) >> >> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes >> and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro. >> >> The PR also fixes the `@summary` tag, which seems to have been copied from >> an unrelated test. > > Eirik Bjørsnøs has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 13 additional > commits since the last revision: > > - Use a small ZIP64 file to reproduce the issue. Convert test to JUnit > - Update copyright year for 2024 > - Use ENTRY instead of FILE when refering to names and sizes of file entries > in the ZIP file > - Merge branch 'master' into zip64-size-test-sparse > - Merge branch 'master' into zip64-size-test-sparse > - Sparse files must be created explicitly on NTFS > - Merge branch 'master' into zip64-size-test-sparse > - Merge branch 'master' into zip64-size-test-sparse > - Make test method public > - Add a missing "when" in Javadocs for SparseOutputStream > - ... and 3 more: https://git.openjdk.org/jdk/compare/d01414fa...41b2ba5e 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? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12948#discussion_r1483943970
