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 (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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2389597190
