On Tue, 8 Feb 2022 18:56:02 GMT, Alan Bateman <al...@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
