On Fri, 11 Feb 2022 17:43:47 GMT, Lance Andersen <lan...@openjdk.org> wrote:
>> src/java.base/share/classes/java/util/jar/JarFile.java line 881:
>>
>>> 879: ze = getJarEntry(entryName);
>>> 880: } else {
>>> 881: throw new ZipException("ZipEntry::getName returned null");
>>
>> Throwing ZipException when ZipEntry::getName returns null is still
>> surprising but not terrible. The spec for getInputStream specifies
>> ZipException for when a zip file format occurs so we might have to extend
>> that to add "or the zip entry name is null".
>
> If you would like me to update the ZipException to clarify this I can. The
> original issue was due to a format error in the CEN so the current wording
> covers that. It does not cover the case where ZipEntry is subclassed and
> ZipEntry::getName() returns null which is what your suggested wording would
> address.
>
> Please note the above change addresses the signed jar scenario. I can add an
> additional check in JarFile::getInputStream to check for null from
> ZipEntry::getName so that it covers unsigned jars and signed jars not being
> verified.
>
> The issue will not occur with ZipEFile::getInputStream given its use of
> ZipEntry.name which can never be null.
>
> Another thought would be to return null for the InputStream similar to when
> the ZipEntry does not represent a file within the Jar
>
> Please let me know your preference
Per a discussion with Sean and Alan, we are now returning null for the
InputStream to be consistent with ZipFile::getInputStream and how unsigned jars
are handled
-------------
PR: https://git.openjdk.java.net/jdk/pull/7348
