RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header [v2]

[Eirik Bjørsnøs]

On Sat, 28 Sep 2024 13:20:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Eirik Bjørsnøs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into zipfile-endhdr
>>  - Merge branch 'master' into zipfile-endhdr
>>  - Do not include the END header when reading the CEN section
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1184:
> 
>> 1182:         private static final int[] EMPTY_META_VERSIONS = new int[0];
>> 1183:         // CEN size is limited to the maximum array size in the JDK
>> 1184:         private static final int MAX_CEN_SIZE = Integer.MAX_VALUE - 2;
> 
> Hello Eirik, (at least) a couple of other places in the JDK (like the `jdk.internal.util.ArraysSupport.SOFT_MAX_ARRAY_LENGTH` and `java.io.InputStream.MAX_BUFFER_SIZE`) use `Integer.MAX_VALUE - 8` as the maximum supported array size. To be consistent, we should use that same here. In fact, `jdk.internal.util.ArraysSupport.SOFT_MAX_ARRAY_LENGTH` is a public field in the JDK and we could just reference it here as follows:
> 
> 
> // CEN size is limited to the maximum array size in the JDK
> private static final int MAX_CEN_SIZE = ArraysSupport.SOFT_MAX_ARRAY_LENGTH;

Thanks, I like that we can delegate  this constant value out of `java.util.zip` where indeed it looks somewhat arbitrary.

I also update the tests `EndOfCenValidation` and `CenSizeTooLarge` to use the same constant, adding `@modules` jtreg tags as needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20905#discussion_r1780737509