On Tue, 2 Jan 2024 12:21:21 GMT, Eirik Bjørsnøs <eir...@openjdk.org> wrote:

>> Please consider this PR which makes `DeflaterOutputStream.close()` always 
>> close its wrapped output stream exactly once.
>> 
>> Currently, closing of the wrapped output stream happens outside the finally 
>> block where `finish()` is called. If `finish()` throws, this means the 
>> wrapped stream will not be closed. This can potentially lead to leaking 
>> resources such as file descriptors or sockets.
>> 
>> This fix is to move the closing of the wrapped stream inside the finally 
>> block.
>> 
>> Additionally, the `closed = true;` statement is moved to the start of the 
>> close method. This makes sure we only ever close the wrapped stream once 
>> (this aligns with the overridden method `FilterOutputStream.close´)
>> 
>> Specification: This change brings the implementation of 
>> `DeflaterOutputStream.close()` in line with its specification:  *Writes 
>> remaining compressed data to the output stream and closes the underlying 
>> stream.*
>> 
>> Risk: This is a behavioural change. There is a small risk that existing code 
>> depends on the close method not following its specification.
>> 
>> Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which 
>> simulates the failure condition and verifies that the wrapped stream was 
>> closed under failing and non-failing conditions.
>
> Eirik Bjørsnøs has updated the pull request incrementally with two additional 
> commits since the last revision:
> 
>  - Add more extensive testing of combined write/close failure modes
>  - Don't suppress if finishException is null, mark stream as closed even when 
> closing the wrapped stream failed

test/jdk/java/util/zip/ZipOutputStream/CloseWrappedStream.java line 47:

> 45:      */
> 46:     @Test
> 47:     public void exceptionDuringFinish()  {

Suggestion:

    public void exceptionDuringFinish() {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17209#discussion_r1452026379

Reply via email to