On Mon, 7 Feb 2022 15:16:43 GMT, Sean Mullan <mul...@openjdk.org> wrote:
>> JarFile::getInputStream. mentions ZipException but not JarException which is >> why I chose this. If we change this to JarException, I would need to update >> the javadoc and create a CSR. >> >> Please let me know your preference > > `JarException` is a subclass of `ZipException` though, so I think this would > be ok to throw and still be compliant with the specification. Looking at this a bit more, it looks like `JariFile::initializeVerifier` is the only place currently in `JarFile` that could throw a `JarException` and that method could be called from `JarFile::getInputStream` As `verifiableEntry` is only called from `JarFile::getInputStream `and this change validates the `ZipEntry` for being null, which is should, the only other possible error would be in the unlikely event. `ZipEntry` was subclassed passed into `JarFile::getInputStream` resulting in the call to `ZipEntry::getName` returning null(in which case `ZipFile::getEntry` will return a `NullPointerException`) or the name being invalid resulting once again in a possible null value for the returned `ZipEntry` from `JarFile::getJarEntry` (which calls `ZipFile::getEntry`) I am still leaning towards a `ZipException`, not a `JarException`, thrown from `verifiableEntry`. That being said, I will go with whatever the consensus is. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348
