On Tue, 15 Aug 2023 23:13:00 GMT, Volker Simonis <simo...@openjdk.org> wrote:
> That file is accepted by zip, by the latest JDK8u382, by the JDK20 GA, and > rejected by the 20.0.2. That is a regression in the latest update of JDK11+ > which we trying to solve here. Have you tested your ZIP file with -Djdk.util.zip.disableZip64ExtraFieldValidation=true? That's the system property to disable the additional checking and is the "get out of jail card" for anyone running into issues. As always with changes like this, or other changes that tighten up checking, there is a risk that it will break something, hence the system property to give existing deployments a workaround to continue. In this case, the original change exposed an issue with a number of Apache projects (see the linked bugs in their issue trackers) and a bad bug in the BND tool that was fixed a few years ago. The system property is the temporary workaround until the deployment has versions of the libraries produced with updated versions of these tools, or a JDK update that tolerates a 0 block size. I think the main lesson with all this is that the JDK doesn't have enough "interop" tests in this area. There are dozens of tools and plugins that generate their own ZIP or JAR files. The addition of the ZIP64 extensions a few number of years ago ushered in a lot of interop issues due to different interpretations of the spec. The changes in PR expands the tests a bit but I think a follow on work will be required to massively expand the number of sample ZIP and JAR files that the JDK is tested with. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1680103189
