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 <jeng...@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-r...@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 > >
