RFR: 8377992: (zipfs) Align ZipFileSystem END header validation with the ZipFile implementation

[Lance Andersen]

On Mon, 16 Feb 2026 15:15:28 GMT, Eirik Bjørsnøs <eirbjo at openjdk.org> wrote:

> Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
> 
> This brings two validation checks over to `ZipFileSystem`:
> 
> * Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746)
> * Rejection of END headers with a total entry count which cannot fit within the CEN byte array  (JDK-8341625)
> 
> The test `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is updated to to verify that ZIP files  rejected by the `ZipFile` constructor are now also rejected by `ZipFileSystem.newFileSystem`.
> 
> Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries.  Similar adjustments to `ZipFile` was done in JDK-8341625.
> 
> `ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.

Hi Eirik,

Thank you for your efforts here and overall the changes to ZipFile and ZipFS are fine.

WRT the test, it is preferable that the ZipFS tests are added to open/test/jdk/jdk/nio/zipfs for now so that we have the specific tests co-located.

At some point we may want to revisit our structure for zip and zipfs tests bu that would be separate from this PR

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

PR Review: https://git.openjdk.org/jdk/pull/29747#pullrequestreview-3826848135