Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

[Scott Palmer]

Other than the read-only aspect, is ByteBuffer pretty close to the builder you are looking for? I would think a thin wrapper over a ByteBuffer might be a suitable alternative.  Just a quick thought, I haven’t looked at any proposed code. Scott On Mar 28, 2025, at 6:09 PM, Archie Cobbs <archie.co...@gmail.com> wrote:  This is just a drive-by, opinion-saturated comment, so feel free to ignore... I think the missing puzzle piece here is slightly different/more general than "OutputStream into memory". IMHO what's really missing from the standard toolbox provided by the JDK is the byte equivalent of StringBuilder+String. In other words, just as String is a read-only wrapper for a character array (or array range), and StringBuilder is used to build a String, Java lacks a read-only container for byte array (or range), and an associated builder. The "read-only" part is very important - as with String, the internal byte[] array must be incorruptible and for the same reasons. If we had those two things, they would presumably be optimized for performance already, so you would then have the building block needed to create a more efficient version of ByteArrayOutputStream - by simply wrapping an OutputStream around the builder (better yet, maybe the builder already extends OutputStream). I'm guessing adding such a thing has probably been discussed before and rejected. If that's true, I'm not optimistic a less general solution to the same overall problem would be accepted, but if there is interest on the list for reconsidering such a thing I'd support it. Like many folks, I've had to resort to writing my own implementation of just such a thing in the past (and am happy to share it if interested). -Archie On Fri, Mar 28, 2025 at 7:06 AM Engebretson, John <jeng...@amazon.com> wrote: Hi all!  This message is to discuss the proposal for a public class that is faster/cheaper than ByteArrayOutputStream.  Details are on the ticket [1] so I will only summarize here: - ByteArrayOutputStream is slower than the provided alternative, and wastes memory bandwidth and allocation. - The new alternative cannot replace ByteArrayOutputStream because BAOS exposes two implementation-specific fields. - The problem is broadly present, and different solutions exist in Spring, Tomcat, multiple applications inside my company, and undoubtedly elsewhere. - There are places within the JDK that will benefit from the improved performance.   My goal is to broadly distribute this new datastructure, and the JDK is an obvious place to do it.  My proposal is to publish a new public class, java.io.MemoryOutputStream extends OutputStream.  I acknowledge the difficulties in doing so.   I welcome any thoughts about the problem, solution, or deployment.  I created a draft PR [2] for discussion or questions about the proposed implementation.   1. https://bugs.openjdk.org/browse/JDK-8352891 2. https://github.com/openjdk/jdk/pull/24232 -- Archie L. Cobbs