Brian,
My understand is JDK-6533165 is moving the bytes that are rarely invoked to a
cold method.
Therefore:
====
if (closed) {
throw new IOException("Stream closed");
}
==becomes===
if (closed) {
throw sc();
}
private static IOException sc() {
return new IOException("Stream closed");
}
================================
Since there is no string concatenation in the IOE message there are only a few
bytes that can be shaved off. I didn't benchmark it either case but I would
assume it would matter for the nullOutputStream since the write methods could
be invoked multiple times.
Jason
________________________________________
From: Brian Burkhalter <[email protected]>
Sent: Wednesday, December 6, 2017 2:05 PM
To: Jason Mehrens
Cc: core-libs-dev
Subject: Re: RFR 4358774: Add null InputStream and OutputStream
Jason,
On Dec 6, 2017, at 11:54 AM, Jason Mehrens
<[email protected]<mailto:[email protected]>> wrote:
For nullInputStream would it make any sense to use the ByteArrayInputStream
with a (private static) empty byte array? Maybe 'return new
ByteArrayInputStream("".getBytes());'? One side effect is that mark support
returns true.
As we are trying to retain the behavior of closed streams throwing IOExceptions
I don’t think that BAIS would work here.
Does it make sense to follow the advice
inhttps://bugs.openjdk.java.net/browse/JDK-6533165 with regards to streams
being closed?
I don’t know exactly what you intend here. In the linked issue there is
information to impart, namely the index and the size. Here there is only the
indication that the stream is closed. It’s not clear to me what could be done
here.
Thanks,
Brian
