Make ByteArrayOutputStream.ensureCapacity(int) protected?

[Daniel Gredler]

Hi Roger,

All points noted, thanks -- just wanted to double check on this:

> I don't think you could call it `ensureCapacity()` if it ignores the
request.

If you pass a negative (i.e. invalid) argument, you need to either throw an
exception or ignore the request. Both `ArrayList` and `StringBuilder`
simply ignore calls with negative arguments (i.e. neither `new
ArrayList().ensureCapacity(-1)` nor `new
StringBuilder().ensureCapacity(-1)` throw an exception, they just ignore
the request). The old `Vector` class does the same, though few developers
will be using it at this stage.

All of that to say that as a developer, ignoring an `ensureCapacity()` call
with a negative capacity would not have surprised me in the least, and
would be consistent with the other `ensureCapacity` methods in other core
classes.

Let me know your thoughts on this final point, and I'll move forward with
both the CSR and the PR.

Thanks!

Daniel



On Tue, Jan 6, 2026 at 3:54 PM Roger Riggs <roger.riggs at oracle.com> wrote:

> 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 <roger.riggs at oracle.com> 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
>> >
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260106/75875c87/attachment-0001.htm>