On Tue, 6 Sep 2022 12:56:46 GMT, Markus KARG <d...@openjdk.org> wrote:
>> Thank you for your decision about this issue, so instead of fixing the >> existing bugs I will implement as you outlined. >> >> BTW, locking and rebasing is on the way. > > 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! :-) ------------- PR: https://git.openjdk.org/jdk/pull/6935
