RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2]

Jaikiran Pai jpai at openjdk.java.net
Tue Sep 15 15:57:35 UTC 2020


On Tue, 15 Sep 2020 15:45:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> As for this:
> 
>> As long as the input stream close() method is idem potent this should be safe, and AFAICS that is the case for the two
>> input stream subclasses that can be returned by ZipFile::getInputStream.
> 
> I'm curious, in the context of this change, why idempotency would be a necessity. Would there be a "double close"
> somehow on this InputStream instance?

I think I understand what you meant. You were perhaps talking about the `JarFile.close` triggering the `Cleanable` to
close this `InputStream` in addition to the `try-with-resources` already calling `close` on that stream. Like you
rightly note, the implementation of those streams already handles that aspect correctly.

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

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



More information about the security-dev mailing list