Hi Scott, ByteBuffer can wrap and write into a byte[] array, but it doesn't know how to grow a new, larger array if the original array runs out of room.
Also, ByteBuffer.array() provides "public" access to the underlying bytes, so the only way to make them read-only is to copy. FWIW here's <https://permazen.github.io/permazen/site/apidocs/io/permazen/util/ByteData.html> what I came up with in my own project. It's not particularly fast right now (it does simply array expand/copy) but it could be optimized along the lines of John's idea where you have fixed-sized internal buffers without changing the API. -Archie On Fri, Mar 28, 2025 at 5:36 PM Scott Palmer <swpal...@gmail.com> wrote: > 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 > > -- Archie L. Cobbs
