On Mon, 5 Sep 2022 18:33:43 GMT, Alan Bateman <[email protected]> wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> HexPrinter::transferTo
>
> It looks like this patch is against a repository that hasn't been sync'ed up
> since late 2021. BIS has changed, esp. the locking, so this is why you get
> the merge-conflict label. Look at the implXXX methods to see how the existing
> methods do the locking.
>
> I think I pointed out in one of the early rounds that you'll have to take the
> mark (if set) into account. It may be that you just call super.transferTo
> when markpos == -1.
>
> The other issue that needs consideration is that the draining of the buffered
> bytes will leak the underlying input stream to the target output stream. It
> may be safer to also call super.transferTo when (count - pos) > 0.
@AlanBateman I do not quite understand what would be wrong with the code below
instead of falling back to the super implementation *in case of non-empty
buffer*?
private long implTransferTo(OutputStream out) throws IOException {
if (getClass() == BufferedInputStream.class && markpos < 0) {
int avail = count - pos;
if (avail > 0) {
out.write(getBufIfOpen(), pos, avail);
pos = count;
}
return avail + getInIfOpen().transferTo(out);
} else {
return super.transferTo(out);
}
}
Can you please explain why you proposed to use the super implementation for
non-empty buffer? Just for my understanding. Thanks!
-------------
PR: https://git.openjdk.org/jdk/pull/6935
