RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v13]
Alan Bateman
alanb at openjdk.org
Wed Dec 13 15:55:49 UTC 2023
On Wed, 13 Dec 2023 10:01:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>> So what is the target package for this utility class?
>
>> So what is the target package for this utility class?
>
> If you really want a utility class then a non-public class in java.io is okay. However, I think the starting point for this change is not the utility class, it's about deciding whether to relax the check on the target or do nothing. The concerns with BIS and BAIS do overlap but they are not identical. More specifically, for BAIS, the underlying byte[] can outlive the BAIS object. For BIS, transferTo may return a positive value more than once because the underlying stream is growing. These are the details that need to be worked through.
> @AlanBateman Why not using com.sun as we did it with other internal classes like ChannelInputStream etc.?
com.sun.* is the name space we used a long time ago for JDK-specific APIs and some internal classes. A lot more internal classes in sun.*. 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.
> Regarding your last sentence actually I do not see what "return a positive value more than once" has to do with the actual changed proposed by this PR?
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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1425555299
More information about the core-libs-dev
mailing list