4799358: BufferedOutputStream.write() should immediately throw IOException on closed stream #15361

vyommani · 2023-08-21T14:26:39Z

With the current implementation of BufferedOutputStream if you close the stream and try to write to the closed stream BufferedOutputStream does not throw an IOException until the internal buffer is full. To fix this issue i added a private "ensureOpen" function to BufferedOutputStream which will check if the underline stream is open. If the underline stream is closed "ensureOpen" will throw the IOException.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue
Change requires CSR request JDK-8314870 to be approved

Issues

JDK-4799358: BufferedOutputStream.write() should immediately throw IOException on closed stream (Bug - P4)
JDK-8314870: BufferedOutputStream.write() should immediately throw IOException on closed stream (CSR)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/15361/head:pull/15361
$ git checkout pull/15361

Update a local copy of the PR:
$ git checkout pull/15361
$ git pull https://git.openjdk.org/jdk.git pull/15361/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 15361

View PR using the GUI difftool:
$ git pr show -t 15361

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/15361.diff

Webrev

Link to Webrev Comment

…ion on closed stream

bridgekeeper · 2023-08-21T14:28:16Z

👋 Welcome back vtewari! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2023-08-21T14:30:07Z

@vyommani The following label will be automatically applied to this pull request:

core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2023-08-21T14:34:01Z

Webrevs

01: Full - Incremental (ffc93a71)
00: Full (5a12a6af)

src/java.base/share/classes/java/io/FilterOutputStream.java

AlanBateman · 2023-08-21T14:37:47Z

/csr

openjdk · 2023-08-21T14:39:51Z

@AlanBateman has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@vyommani please create a CSR request for issue JDK-4799358 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

liach · 2023-08-21T15:01:31Z

write(int) should have an ensureOpen check too.

bplb · 2023-08-23T21:41:41Z

src/java.base/share/classes/java/io/FilterOutputStream.java

+     * @return {@code true} if, and only if, this stream is open
+     */
+    boolean isOpen(){
+        return !closed;


Wouldn't you want synchronized (closeLock) here?

'closed' is volatile, we don't need synchronized (closeLock) here.

bplb · 2023-08-23T21:42:33Z

test/jdk/java/io/BufferedOutputStream/WriteAfterClose.java

+import java.io.IOException;
+import java.io.OutputStream;
+import java.io.File;
+import java.io.FileOutputStream;


The imports should be in alphabetical order per convention.

bplb · 2023-08-23T21:46:34Z

test/jdk/java/io/BufferedOutputStream/WriteAfterClose.java

+
+    public static void main(String argv[]) throws IOException {
+        var file = new File(System.getProperty("test.dir", "."), "test.txt");
+        file.createNewFile();


Why not instead do something like?:

var dir = new File(System.getProperty("test.dir", ".")); File file = File.createTempFile("x", "y", dir);

I don't think you need to specify test.dir

'test.dir' is not necessary, but it's a convention currently used in more than 50 IO and NIO tests. Probably not so useful here.

bplb · 2023-08-23T21:54:31Z

The proposed change does not appear to add a great deal of value and breaks longstanding behavior. In such cases, the preferred approach is usually to modify the specification to match the current, albeit incorrect, behavior rather than to change the code itself. Given that this issue was filed more than two decades ago suggests that changing the implementation would be likely to break code which unwittingly depends on the longstanding behavior.

bplb · 2023-08-23T22:00:45Z

The PR title should be changed to match the JBS issue summary.

vyommani · 2023-08-24T04:24:21Z

The proposed change does not appear to add a great deal of value and breaks longstanding behavior. In such cases, the preferred approach is usually to modify the specification to match the current, albeit incorrect, behavior rather than to change the code itself. Given that this issue was filed more than two decades ago suggests that changing the implementation would be likely to break code which unwittingly depends on the longstanding behavior.

I am unable to understand how proposed change breaks longstanding behavior(what behavior). With current implementation if the underline stream is closed ‘BufferedOutputStream.write’ will throw IOException when the internal buffer is full. With the proposed change BufferedOutputStream will throw IOException immediately . I don’t see any reason in not throwing exception and waiting till internal buffer fills.

All other OutputStream implementations internally checks and throw IOException immediately if the stream is close. So with the proposed change 'BufferedOutputStream' will behave the same.

Do you really think there is code outside which do ‘write’ after closing the stream, and proposed change will break it ?.

AlanBateman · 2023-08-24T06:36:37Z

I am unable to understand how proposed change breaks longstanding behavior(what behavior). With current implementation if the underline stream is closed ‘BufferedOutputStream.write’ will throw IOException when the internal buffer is full. With the proposed change BufferedOutputStream will throw IOException immediately.

The change means that IOException will be thrown for cases where it isn't currently thrown. It also means that IOException may be thrown at different use-sites that it is now. I don't think anyone is disagreeing that there is a long standing bug, the issue is that changing the behavior will likely be observed. In cases like this, we will often decide to just specify long standing behavior as the compatibility impact of fixing something is too high.

In this case, I don't object to fixing it early in JDK 22 but the change will need to be widely tested so as to shake out any bugs in code in the eco system as early as possible. It might be that after a few weeks/months that we get some confidence that it is okay, or it might be that we decide to introduce a system property to restore long standing behavior, or decide to just back it out. The question is whether we can get enough testing of JDK 22 builds to help decide on this.

bridgekeeper · 2023-09-21T15:48:45Z

@vyommani This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

bridgekeeper · 2023-10-20T00:48:45Z

@vyommani This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

4799358: BufferOutputStream.write() should immediately throw IOExcept…

5a12a6a

…ion on closed stream

openjdk bot added the rfr label Aug 21, 2023

openjdk bot added the core-libs label Aug 21, 2023

AlanBateman reviewed Aug 21, 2023

View reviewed changes

src/java.base/share/classes/java/io/FilterOutputStream.java Outdated Show resolved Hide resolved

openjdk bot added the csr label Aug 21, 2023

make the isOpen method to package private

ffc93a7

bplb reviewed Aug 23, 2023

View reviewed changes

vyommani changed the title ~~4799358: BufferOutputStream.write() should immediately throw IOExcept on closed stream~~ 4799358: BufferOutputStream.write() should immediately throw IOException on closed stream Aug 24, 2023

vyommani changed the title ~~4799358: BufferOutputStream.write() should immediately throw IOException on closed stream~~ 4799358: BufferedOutputStream.write() should immediately throw IOException on closed stream Aug 25, 2023

bridgekeeper bot closed this Oct 20, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

4799358: BufferedOutputStream.write() should immediately throw IOException on closed stream #15361

4799358: BufferedOutputStream.write() should immediately throw IOException on closed stream #15361

vyommani commented Aug 21, 2023 •

edited by openjdk bot

Loading

bridgekeeper bot commented Aug 21, 2023

openjdk bot commented Aug 21, 2023

mlbridge bot commented Aug 21, 2023 •

edited

Loading

AlanBateman commented Aug 21, 2023

openjdk bot commented Aug 21, 2023

liach commented Aug 21, 2023

bplb Aug 23, 2023

vyommani Aug 24, 2023

bplb Aug 23, 2023

bplb Aug 23, 2023

LanceAndersen Aug 23, 2023

bplb Aug 23, 2023

bplb commented Aug 23, 2023

bplb commented Aug 23, 2023

vyommani commented Aug 24, 2023

AlanBateman commented Aug 24, 2023

bridgekeeper bot commented Sep 21, 2023

bridgekeeper bot commented Oct 20, 2023

4799358: BufferedOutputStream.write() should immediately throw IOException on closed stream #15361

4799358: BufferedOutputStream.write() should immediately throw IOException on closed stream #15361

Conversation

vyommani commented Aug 21, 2023 • edited by openjdk bot Loading

Progress

Issues

Reviewing

Webrev

bridgekeeper bot commented Aug 21, 2023

openjdk bot commented Aug 21, 2023

mlbridge bot commented Aug 21, 2023 • edited Loading

Webrevs

AlanBateman commented Aug 21, 2023

openjdk bot commented Aug 21, 2023

liach commented Aug 21, 2023

bplb Aug 23, 2023

Choose a reason for hiding this comment

vyommani Aug 24, 2023

Choose a reason for hiding this comment

bplb Aug 23, 2023

Choose a reason for hiding this comment

bplb Aug 23, 2023

Choose a reason for hiding this comment

LanceAndersen Aug 23, 2023

Choose a reason for hiding this comment

bplb Aug 23, 2023

Choose a reason for hiding this comment

bplb commented Aug 23, 2023

bplb commented Aug 23, 2023

vyommani commented Aug 24, 2023

AlanBateman commented Aug 24, 2023

bridgekeeper bot commented Sep 21, 2023

bridgekeeper bot commented Oct 20, 2023

vyommani commented Aug 21, 2023 •

edited by openjdk bot

Loading

mlbridge bot commented Aug 21, 2023 •

edited

Loading