RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v6]

[Eirik Bjorsnos]

On Mon, 13 Mar 2023 01:31:20 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - MAX_EXTRA_FIELD_SIZE can be better expressed as 0xFFFF
>>  - Bring back '@requires sun.arch.data.model == 64' for now
>
> test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 53:
> 
>> 51: 
>> 52:     // Maximum size (unsigned short) of an extra field allowed by the standard
>> 53:     static final int MAX_EXTRA_FIELD_SIZE = 0XFFFF;
> 
> 4.4.10 file name length: (2 bytes)
>    4.4.11 extra field length: (2 bytes)
>    4.4.12 file comment length: (2 bytes)
> 
>        The length of the file name, extra field, and comment
>        fields respectively.  The combined length of any
>        directory record and these three fields SHOULD NOT
>        generally exceed 65,535 bytes.

`The combined length of any directory record and these three fields SHOULD NOT generally exceed 65,535 bytes.`

I was not aware of this 'combined length' clause. Are you suggesting we take this into account in this test? I feel that would be somewhat strange, given that this constraint seems not be be enforced at all by ZipEntry or ZipOutputStream:


ZipEntry(String name):

if (name.length() > 0xFFFF) {
    throw new IllegalArgumentException("entry name too long");
}



ZipOutputStream.writeCEN:

if (commentBytes != null) {
    writeBytes(commentBytes, 0, Math.min(commentBytes.length, 0xffff));
}

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

PR: https://git.openjdk.org/jdk/pull/12991