Make ByteArrayOutputStream.ensureCapacity(int) protected?

[Roger Riggs]

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/8304bc54/attachment.htm>