RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2]

[Lance Andersen]

On Tue, 8 Feb 2022 18:56:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> I'm almost tempted to have getInputStream(ZipEntry) be re-specified to throw IAE if the zip entry name is null.
>> 
>> I personally think it is best to continue throw the NPE as that provides symmetry with ZipFile::getInputStream,  aligns with the current javadoc where a null parameter will throw an NPE unless specified elsewhere,  there are existing tests which check for an NPE if JarFile::getInpuStream(null) is called.
>
>> I personally think it is best to continue throw the NPE as that provides symmetry with ZipFile::getInputStream, aligns with the current javadoc where a null parameter will throw an NPE unless specified elsewhere, there are existing tests which check for an NPE if JarFile::getInpuStream(null) is called.
> 
> I think the scenario that we are discussing is where the parameter is not null. It's the case where getInputStream(ZipEntry) is called with a ZipEntry that reports its name as null. I don't think it is covered by existing javadoc.

Ah, OK, sorry I was focused on the NPE and uber focused on the `ZipEntry` passed to `getInputStream`.

If you *prefer* an IAE, I can change that when `ZipEntry::getName` returns null.  I do think we are technically covered via `ZipException` which is defined : ` if a zip file format error has occurred` and unless something has gone amiss with the Zip/Jar LOC/CEN, you should expect a non-null value.

Please let me know your preference as if we go the IAE route, I will need to create a CSR which I was hoping to avoid

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

PR: https://git.openjdk.java.net/jdk/pull/7348