RFR: 8279283 - BufferedInputStream should override transferTo [v7]

[Daniel Fuchs]

On Tue, 6 Sep 2022 13:00:23 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Rebased and fixed locking, using your proposed code now.
>> 
>> @AlanBateman  Async close leaves BIS in an invalid state. The JavaDocs say ` The behavior for the case where the inputand/or output stream is asynchronously closed, or the thread interrupted during the transfer, is highly input and output streamspecific, and therefore not specified.`. So there is seems to be no *essential* need to do something *particular* in that case (the caller cannot further use the BIS, just like after an IOE: `It is strongly recommended that both streams be promptly closed if an I/O error occurs.` -- which is what *I personally, as a user of BIS* would do after async close), but if you *want* that we reach a particular outcome, then just tell me what outcome you envision.
>
>> With the changes you proposed a CSR will definitely be needed.
> 
> @dfuch Just to learn about OpenJDK rules: Why? I always thought that CSR is only needed when breaking *documented* behavior. Do you have a link to the official rule that proofs your claim in *this* case (i. e. *non-documented* behavior)? Thanks! :-)

Hi Markus, It's a good idea to write a CSR if your change modifies an observable behavior that users of the public API (including custom subclasses) might be depending on. This is both to raise the awareness on the impact of the change, document the possible regression risks, and get feedback from the CSR committee who might suggest mitigating actions to reduce the risk (such as e.g: adding a property to make it possible to revert to the old behavior, write a release note, etc...). In the case at hand `BufferedInputStream` is a very old class that has been used and abused all over the board in the java ecosystem. So writing a CSR to document a change in behavior that some subclasses may be depending on would be the proper thing to do, when changing that behaviour. The fact that you have found such a subclass (with a legitimate use case) only strengthen the need for exercising such care.
In retrospect it would have been much better if `BufferedInputStream` had been declared final - but it's much too late for that now. Thanks!

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

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