On 21/04/2025 17:46, Engebretson, John wrote:
Following up on MemoryOutputStream, etc. – the conversation has
considered a few alternatives:
1. Hide the new class behind ByteArrayOutputStream.unsynchronized()
2. Create a new public class providing views to OutputStream, Channel,
InputStream
3. Something to do with an Object[] variant
I would personally reject any code review that used
“unsynchronized()” to describe this class, since that is only a minor
property of the change. I could live with “scalable” or something
along those lines.
A new public class provides more capabilities than I initially
proposed, but of course requires a new public class. 😊
The Object[] variant is interesting but I have no pressing need for
it. This probably gets a pin in it unless someone provides a use case.
Maybe the two efforts should be separated.
The removal of biased locking has shinned light on the synchronization
in BAIS/BAOS. It's been there since JDK 1.0 and too risky to change. We
need to decide whether to specify this long standing behavior. We also
need to explore adding a factory method to both to obtain a stream that
isn't thread safe. The factory methods can return a different
implementation, in particular BAOS.unsynchronized (or whatever name it
gets) does not need to collect the bytes in a contiguous array. So
having a BAOS.unsynchronized may help with some of the scenarios that
you are looking at.
I think the PR proposing MemoryOutputStream is a bit premature and it
will take a bit more work, and prototypes, to get a handle on the
problem and help inform if a standard API makes sense. A sink that can
collect an unbounded number of bytes could be fun to try to optimize for
different usages. What isn't clear from the exploration so far is how to
interface to other APIs. A method to return a byte[], like
BAOS::toByteArray, is problematic when the number of bytes don't fit in
an int. Maybe you have explored a segment like API or a cursor or
consumer API to handle the bytes?
-Alan
