JDK-8352891 Performance improvements to ByteArrayOutputStream

[Engebretson, John]

  Thank you Alan!  I’ll try to address each of your points, apologies if I miss anything:

        Maybe the two efforts should be separated.

  I’m good with that, and will operate that way unless someone argues otherwise.

       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 this is a clever way to go and I’m in favor… just not sold on the name.  I won’t abandon the effort if you feel otherwise.  😊  Let me know if we’re ready to proceed with this or another name.

      I think the PR proposing MemoryOutputStream is a bit premature

  This was intended solely to share code for discussion, and it’s been effective in that sense.  I agree that the PR is nowhere near merging.

      Maybe you have explored a segment like API or a cursor or consumer API to handle the bytes?

  The current version of the PR is along these lines, providing one public class whose contents are available via views (SeekableByteChannel, BAOS, ByteArrayInputStream) as well as the usual add/write/updates, long size(), and lambda-based applyToSegment(Function) and applyToIndex(Function).  The public wrapping needs to evolve but I think these provide the core of the API.
    John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250422/dfb72780/attachment.htm>