RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted [v2]
Markus KARG
duke at openjdk.org
Fri Dec 1 13:50:04 UTC 2023
On Fri, 1 Dec 2023 04:01:42 GMT, jmehrens <duke at openjdk.org> wrote:
>> I might have done this incorrectly, but with this version of the above `wolf` I do not see any corruption:
>>
>> java.nio.channels.WritableByteChannel wolf =
>> new java.nio.channels.WritableByteChannel() {
>> private boolean closed = false;
>>
>> public int write(java.nio.ByteBuffer src) throws IOException {
>> int rem = src.remaining();
>> Arrays.fill(src.array(), src.arrayOffset() + src.position(),
>> src.arrayOffset() + src.limit(),
>> (byte)'0');
>> src.position(src.limit());
>> return rem;
>> }
>>
>> public boolean isOpen() {
>> return !closed;
>> }
>>
>> public void close() throws IOException {
>> closed = true;
>> }
>> };
>
> @bplb You did it right. The reason it works is because the ChannelOutputStream is in the "sun." package and not the "java." package. That is not the case for Channels.newOutputStream(AsynchronousByteChannel ch) as that wrapper should be able to access the byte array.
I see the problem that unless we have an explicit whitelist, we do open the risk of accidentially adding another wrapper stream in future to the JDK somewhere and forget to add it to the blacklist. So for safety, I would pleae for not using .startsWith() but explitly mention the actively proven-as-safe classes only. That way, the code might be slower (sad but true) but inherently future-proof.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1412123464
More information about the core-libs-dev
mailing list