On Tue, 10 Sep 2024 05:46:46 GMT, Jaikiran Pai <j...@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
