Hi Daniel,
I don't think you could call it `ensureCapacity()` if it ignores the
request.
The limit is not specified, different VMs have different overheads.
The exception and message are appropriate: "java.lang.OutOfMemoryError:
Requested array size exceeds VM limit "
For negative arguments, an IllegalArgumentException might be an
improvement in usability for developers.
[2] 8258565 is closed as "will not fix" because the memory limits are an
implementation parameter, not specified.
Thanks, Roger
p.s. as an API change it will need a CSR. There's a "create a CSR" menu
item on the issue and a template to fill out.
On 1/6/26 9:01 AM, Daniel Gredler wrote:
Hi Roger,
Thanks for the feedback, I've created an issue in JBS [1] and will
create the PR in the coming days.
This method currently throws an OOME if a negative capacity is
requested, but that should never happen because it's only called
internally after careful parameter validation. Once it's public, users
will be able to request negative capacities directly. For the public
API, I'm leaning towards quietly ignoring calls with non-positive
capacities, a la `AbstractStringBuilder`, instead of throwing an OOME.
Let me know if you agree?
Also, do you know what the maximum possible requested capacity is
here? It would be good to avoid the need for follow-up issues like
this one [2] for `ArrayList`.
Take care,
Daniel
[1] https://bugs.openjdk.org/browse/JDK-8374610
[2] https://bugs.openjdk.org/browse/JDK-8258565
On Mon, Jan 5, 2026 at 3:54 PM Roger Riggs <[email protected]> wrote:
Hi Daniel,
That seems reasonable, allowing control over the timing of resizes.
Making it public is sensible too.
From a higher point of view, are you sure you want to be working
with
ByteArrayOutputStream and not ByteBuffer or Memory Segments? There
are
more performance possibilities with those APIs.
Regards, Roger
On 1/5/26 7:15 AM, Daniel Gredler wrote:
> Hi,
>
> I was recently looking at subclassing `ByteArrayOutputStream` in an
> application so that I could add a fast VarHandle-based
> `writeLong(long)` method (writing 8 bytes to the byte array in one
> go). The internal `ByteArrayOutputStream` buffer is protected,
so no
> issue there, but `ensureCapacity(int)` is private rather than
> protected, and uses the internal `ArraysSupport` class, so it's not
> even easy to copy/paste as duplicate code in the subclass. Similar
> `ensureCapacity` methods in `ArrayList` and `StringBuilder` are
> public. Would a PR adjusting the visibility of this method from
> private to protected be accepted?
>
> Take care,
>
> Daniel
>
>
