RFR: 8294696 - BufferedInputStream.transferTo should drain buffer when mark set

[Markus KARG]

On Mon, 17 Oct 2022 11:14:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > @AlanBateman WDYT? Is such a test mandatory to include this rather simple PR?
>>> 
>>> I think it means checking that test/jdk/java/io/BufferedInputStream/TransferTo.java exercises this code path, I expect it should.
>>> 
>>> It might seem a "rather simple PR" but it leaks a reference to the internal buffer to the target and we need to get comfortable with that. It only does then when there is no mark (good) so this should mostly limit the concern to sources where EOF may be encountered more than once.
>> 
>> Which kind of sources would do that, and is there a way to check it and prevent it?
>> 
>> The whole issue points to an insufficiency in the API: it is lacking a way to transfer buffers in a read-only fashion (like NIO could do). I don't suppose we would want to change that, though, right?
>
>> Which kind of sources would do that, and is there a way to check it and prevent it?
>> 
>> The whole issue points to an insufficiency in the API: it is lacking a way to transfer buffers in a read-only fashion (like NIO could do). I don't suppose we would want to change that, though, right?
> 
> It can arise with many sources. One example is a program writing to a file and another reading from the same file and doing the equivalent of "tail -f". So yes, it is possible for transferTo to transfer >0 bytes after it a previous innovation has returned 0.

@AlanBateman To progress with this PR, what do you expect me to do? Do you want me to provide a test that proofs that this particular example will work fine? Or do you like me to simply copy the buffer instead of leaking it?

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

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