RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line

[Eirik Bjørsnøs]

On Fri, 10 Mar 2023 15:48:40 GMT, Alan Bateman <alanb 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' 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.
>
> 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.

Not sure I understand. I could use FileChannel.open with SPARSE (which btw is ignored by the implementation:), but that doesn't give me an OutputStream I can pass to ZipOutputStream?

I could use Channels.newOutputStream, but that would not create holes in the sparse files?

My current thinking is that we need the SparseOutputStream to detect that ZIpOutputStream is writing empty bytes and replace that with `channel.position(channel.position() + len)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1132554394