RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files

[fitzsim]

On Wed, 12 Jun 2024 14:02:58 GMT, fitzsim <duke at openjdk.org> wrote:

> 8334048: -Xbootclasspath can not read some ZIP64 zip files

It turns out ZIP64 is underrepresented in the test suite in general; for example, https://bugs.openjdk.org/browse/JDK-8185896 is still open.

Using the Java class library alone, I have not been able to produce a ZIP file that demonstrates this issue.

I have ideas about how the standard ZIP classes could be modified to produce small ZIP64 files suitable for testing various code paths.

I was able to produce a small ZIP file using the Info-ZIP command line tool that does demonstrate the issue.

To keep the test setup simple, I inlined the ZIP file as byte constants in `BootClassPathZip64Creator`, the driver for `BootClassPathZip64Test`.

Next I am going to check the code coverage provided by this test case for the proposed `zip_util.c` fix.

I saw and looked into this failure:

`2024-07-03T09:37:42.6540920Z 	at ZipSourceCache.testKeySourceMapping(ZipSourceCache.java:102)`
...
`Suppressed: java.nio.file.FileSystemException: 1719999454994-bug8317678.zip: The process cannot access the file because it is being used by another process`

but I could not see how `zip_util.c` could cause that.

I re-ran [windows-x64 / test (jdk/tier1 part 2)](https://github.com/fitzsim/jdk/actions/runs/9774287212/job/26997159267) and that issue resolved itself.  I am not sure at this point if this could be caused by the `zip_util.c` changes, or if it is a transient `windows-x64` builder issue.

I was able to get the same _"invalid CEN header (bad signature)"_ error for `-Xbootclasspath` with a ZIP file generated using the `ZipFileSystem` API, using `Map<String, Object> env = Map.of("create", "true", "forceZIP64End", "true");` like `readZip64EndZipFs` does in `test/jdk/java/util/zip/ZipFile/ReadZip.java` (https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/ReadZip.java#L230).  Given it is the same failure mode, I am inclined not to add a Java part to the test case.

I noticed that `readZip64EndInfoZIPStreaming` in that same test case uses the approach I found independently for creating a small ZIP64 file, and it also inlines the bytes of that small ZIP file.  Therefore the inlining approach in `BootClassPathZip64Creator` does not regress [JDK-8321616](https://bugs.openjdk.org/browse/JDK-8321616).

I still would like to exercise at least one branch of the heuristics conditional with another test case, so I will work on that next.  At that point, I suspect one could argue that [JDK-8185896](https://bugs.openjdk.org/browse/JDK-8185896) is addressed, unless one would prefer to create another set of expensive tests using large-payload ZIP64 files.

This patch set is ready for review.  I was able to eliminate the Info-ZIP dependency and shrink the test logic significantly.  I added two new test cases, one for non-ZIP64 ZIP files, and one for a ZIP64 file with magic values in CEN, both of which worked before and continue to work with the fix proposed in this pull request.

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

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2204456736
PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2206421991
PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2229497634
PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2261474735