On Tue, 6 Sep 2022 16:29:39 GMT, Alan Bateman <[email protected]> wrote:
>> 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.
Thank you all for your kind help and feedback.
@AlanBateman So is now the time to switch this PR from Draft to Ready?
-------------
PR: https://git.openjdk.org/jdk/pull/6935
