JDK-8352891 Performance improvements to ByteArrayOutputStream

[Stephen Colebourne]

I agree that ByteArrayOutputStream is a problem child, and often a
performance pain. While it probably doesn't add much to the debate, I
recently wrote my own replacement class
https://github.com/JodaOrg/joda-beans/blob/main/src/main/java/org/joda/beans/ser/LinkedByteArrayOutputStream.java
thanks
Stephen


On Mon, 12 May 2025 at 15:36, Engebretson, John <jengebr at amazon.com> wrote:
>
>   Friendly ping.  There seems to be support for this idea in some form (especially on the PR) but I haven’t received anything definitive from this email discussion.  The safest proposal on the table is from @liach: make this a JDK-internal class (for now) and modify JDK classes to rely on it.  Assuming good results, we consider making it public in future releases.
>
>   Could I please get some form of signoff from the core team?  I’d really like to deliver something here soon, otherwise I have to move on.
>
>   Thank you very much!  😊
>
>     John
>
>
>
> From: core-libs-dev <core-libs-dev-retn at openjdk.org> On Behalf Of Engebretson, John
> Sent: Tuesday, April 22, 2025 7:52 AM
>
>
>
>   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
>
>