RFR: 8303972: Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line [v3]

[Alan Bateman]

On Fri, 10 Mar 2023 20:50:05 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
>> 
>> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' extended field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).
>> 
>> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.
>> 
>> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The Zip64 fields are all zero, we don't need to update them

test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 136:

> 134:         // Make a ZIP with two entries
> 135:         try (FileOutputStream fileOutputStream = new FileOutputStream(new File(ZIP_FILE_NAME));
> 136:              ZipOutputStream zo = new ZipOutputStream(new SparseOutputStream(fileOutputStream))) {

Can you use FileChannel.open and specify SPARSE in the set of open options, I think that would make it clearer that the file is sparse and remove the need for SparseOutputStream.

-------------

PR: https://git.openjdk.org/jdk/pull/12979