On Mon, 5 Sep 2022 18:33:43 GMT, Alan Bateman <al...@openjdk.org> 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