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