Make ByteArrayOutputStream.ensureCapacity(int) protected?

[Roger Riggs]

Hi Daniel,

I stand corrected, any current size (>=0) satisfies the request (zero is 
greater than -1).

I would not say it "ignores" it, just that it already is greater or 
equal to the request.
The current phrasing of ByteArrayOutputStream.ensureCapacity uses the 
"holds at least" phrasing.
It would risky to change the implementation of BAOS.ensureCapacity to 
not throw OOME on negative minCapacity.

Roger


On 1/6/26 1:30 PM, Daniel Gredler wrote:
> 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/2d9c18de/attachment-0001.htm>