RFR: 8279283 - BufferedInputStream should override transferTo [v7]

[Alan Bateman]

On Tue, 6 Sep 2022 12:14:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the changes you proposed a CSR will definitely be needed.
>
> BIS dates from JDK 1.0 and it's not hard to find examples that extend it. The HexPrinter test reminds us that it has been possible for 25+ years to override the read methods and snoop on all bytes that are read. Adding an override of the transferTo method that bypasses the read methods might break these subclasses. So I think Daniel is right that we have to be cautious.
> 
> So I think the feedback that you have now is that bypassing the buffer is problematic when using mark, when there are buffered bytes, or when BIS has been extended. It may be that the starting point is something very conservative like this:
> 
> 
>     @Override
>     public long transferTo(OutputStream out) throws IOException {
>         if (getClass() == BufferedInputStream.class
>                 && ((count - pos) <= 0) && (markpos == -1)) {
>             return getInIfOpen().transferTo(out);
>         } else {
>             return super.transferTo(out);
>         }
>     }
> 
> 
> There is also the issue of locking and async close to look into.

> @AlanBateman Async close leaves BIS in an invalid state. The JavaDocs say ` The behavior for the case where the input and/or output stream is asynchronously closed, or the thread interrupted during the transfer, is highly input and output stream specific, and therefore not specified.`. 

Yes, I believe I suggested that wording when the method was added. The java.io APIs mostly pre-date deep consideration of those topics.

I've looked at the update change to BIS in f2f9a904 and I think it's okay.

On the CSR topic and your messages with Daniel. On the CSR wiki pages then phrase to look for is "behavioral compatibility".  The "Kinds of Compatibility" has more details on the topic.

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

PR: https://git.openjdk.org/jdk/pull/6935