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

[Andrew John Hughes]

On Tue, 10 Sep 2024 05:46:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I pushed the review suggestions.  There were two GitHub Actions failures on `macos-aarch64`, but they look to be occurrences of this existing bug: https://bugs.openjdk.org/browse/JDK-8247940.
>
> Hello @fitzsim, I plan to take a look at this change and also consult with others familiar with the bootclasspath area as well as jar/zip area. I am just noting this now to let you know that the PR hasn't been neglected and I think it will take a while for this to be reviewed given the nature and area of this change.

> Sounds good @jaikiran.
> 
> I can provide some background about this pull request; it was the result of discussions on a related jdk8u-dev pull request ([openjdk/jdk8u-dev#452](https://github.com/openjdk/jdk8u-dev/pull/452)).
> 
> Red Hat has been shipping the `zip_util.c` change proposed here, authored by @gnu-andrew, as a patch to our Red Hat Enterprise Linux `java-1.8.0-openjdk` packages since mid-2020. In that release all `ZIP` files the `JDK` uses are processed by `zip_util.c` unless someone is using the demo `Java` implementation. We have had no field reports of issues with the patch.
> 
> @gnu-andrew and I would like to upstream `ZIP64` support to `jdk8u`, but the `zip_util.c` patch only exists within Red Hat's package repository, not anywhere upstream from where it could be backported.
> 
> When I checked for the most recent branch that still shipped `zip_util.c`, I discovered that even mainline still ships it, albeit now only for use in `-Xbootclasspath` handling. So I split the `zip_util.c` patch out and added some tests to demonstrate the bug itself and that there should be no regressions, and filed this pull request.
> 
> If this is accepted into mainline and gets some broader testing with no issue, then I would like to backport it to 21, 17, 11, and 8.

Just to add to this, while the `zip_util.c` changes are unique to our 8u patch, they are a conversion to C of the equivalent Java changes made in [JDK-8186464](https://bugs.openjdk.org/browse/JDK-8186464), with the intention to backport that change to 8u without the risk of [JDK-8145260](https://bugs.openjdk.org/browse/JDK-8145260), which introduces the Java-based implementation. So if there is a risk in this patch, it is likely a risk of a mistake in the translation to C rather than the general gist of the changes, which are present in the JDK's Java zip code.

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

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2468614066