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
