On Thu, 8 Sep 2022 08:22:14 GMT, Markus KARG <d...@openjdk.org> wrote:
>> Agreed that testing the non-empty-buffer (read-before-transferTo) and the >> mark-set cases (mark-before-transferTo), but still I do not see any need to >> take particularly `FileInputStream` into the boat; files only make the test >> run slower. > > I have just added testing `transferTo` with non-empty buffer and mark set as > part of the already existing *randomized* test steps. I think that should be > sufficient to detect problems if they really would exist, so there should not > be a real need to run *explicit and separate* test cases for the combinations > of "buffered with mark" / "buffered without mark" / "unbuffered with mark" / > "unbuffered without mark" as that would not provide any improved coverage or > detection rate IMHO. My intention of suggesting a test where it uses something like a FileInputStream was to trigger the code path that would invoke the `FileChannel#transferTo` when such an `InputStream` was wrapped in a `BufferedInputStream`. The `FileChannel#transferTo` in its javadoc states that it can throw exceptions that aren't `IOException` (for example `NonReadableChannelException` which is a `IllegalStateException`). So it was just an attempt to see if such a testing uncovers something that might make us consider catching those exceptions in this new implementation of `BufferedInputStream#transferTo` and rethrow it as an `IOException`. ------------- PR: https://git.openjdk.org/jdk/pull/6935
