On Wed, 13 Dec 2023 16:46:16 GMT, Alan Bateman <al...@openjdk.org> wrote:
>>> It doesn't make sense here to add a new package com.sun.io for a single >>> method class. This PR does not need to introduce any new classes at this >>> point. I think this PR needs to focus solely on BIS. >> >> So you actually prefer copy-and-paste and duplicated code? >> >>> On the surface, transferTo reads to EOF so there are no more bytes to read >>> from the underlying stream or byte[]. Adding a "growing file" and it breaks >>> assumptions. So it's an important discussion point in this topic. >> >> I still do not see what this has to do with the *actual* changes proposed by >> this PR. Can you please provide an example in what situation the *actual* >> changes proposed by this PR will fail in that case, while the original code >> will succeed? > >> > It doesn't make sense here to add a new package com.sun.io for a single >> > method class. This PR does not need to introduce any new classes at this >> > point. I think this PR needs to focus solely on BIS. >> >> So you actually prefer copy-and-paste and duplicated code? > > It's not important at this time, the starting point is to decide if > BIS.transferTo should be changed or not. It does shared some concerns with > BAIS but the set of concerns for both is not identical. > the underlying byte[] can outlive the BAIS object I guess this is true only for target OutputStreams incorporating another one or OutputStreams deliberately made malicious. For classes enumerated in IOStreams this is not a case, I think. > For BIS, transferTo may return a positive value more than once because the > underlying stream is growing As of this I don't understand how it affects the change. The JavaDoc of InputStream.transferTo() explicitly says that the method ` Reads all bytes from this input stream and writes the bytes to the given output stream` and I guess all the data is read only once ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1425794463
