> It would risky to change the implementation of BAOS.ensureCapacity to not throw OOME on negative minCapacity.
Completely agree -- if we wanted the public API contract to match the `ensureCapacity` method behavior elsewhere, we would leave the existing method untouched and private, and add a public version which only delegates to the existing private method if minCapacity > 0 (almost identical to `AbstractStringBuilder`). Take care, Daniel On Tue, Jan 6, 2026 at 8:53 PM Roger Riggs <[email protected]> wrote: > 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 <[email protected]> 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 <[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 >>> > >>> > >>> >>> >> >
