<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Hi Daniel,<br>
<br>
CSR's get few reviewers than PR's. <br>
<br>
A broader review in the PR can improve the prose and get comments on
additional use cases.<br>
For myself, I do them in parallel, putting the initial CSR in
proposed state to get early feedback from the CSR review.<br>
Comments on the PR accumulate and are addressed in the PR and when
that settles down, update the PR and finalize.<br>
<br>
In the CSR, the Compatibility Risk description highlights a typical
more serious risk, that of superseding an existing method in an
implementation and possibly changing or being in conflict with its
semantics. As a protected method, its potential to be in conflict
with existing implementations is reduced somewhat.<br>
<br>
The diff in the CSR should focus on the specification change, not
the implementation changes unless they affect visible behavior.
(Generally, avoid irrelevant information in the CSR).<br>
<br>
BTW, P4 is a better priority for this useful addition, P5 is pretty
much ignored or trivial and not worth it.<br>
<br>
Thanks for the followup, Roger<br>
<br>
<br>
<div class="moz-cite-prefix">On 1/7/26 4:07 PM, Daniel Gredler
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAPA+ug52Rr-dEt1+8YNpEGk07OtJ70ncsvD3oVsRPhLn3p_CXA@mail.gmail.com">
<div dir="ltr">
<div>Hi Roger,</div>
<div><br>
</div>
<div>I've created the CSR here: <a href="https://bugs.openjdk.org/browse/JDK-8374739" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8374739</a></div>
<div><br>
</div>
<div>Alan also provided some feedback on the original issue
here: <a href="https://bugs.openjdk.org/browse/JDK-8374610" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8374610</a></div>
<div><br>
</div>
<div>I was going to wait to create the PR until the CSR has been
approved, if that's OK?</div>
<div><br>
</div>
<div>Take care,</div>
<div><br>
</div>
<div>Daniel</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Tue, Jan 6, 2026 at 9:05 PM
Daniel Gredler <<a href="mailto:djgredler@gmail.com" moz-do-not-send="true" class="moz-txt-link-freetext">djgredler@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>> It would risky to change the implementation of
BAOS.ensureCapacity to not throw OOME on negative
minCapacity.<font color="#888888"><br>
</font></div>
<div><br>
</div>
<div>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`).</div>
<div><br>
</div>
<div>Take care,</div>
<div><br>
</div>
<div>Daniel</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jan 6, 2026 at
8:53 PM Roger Riggs <<a href="mailto:roger.riggs@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">roger.riggs@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> Hi Daniel,<br>
<br>
I stand corrected, any current size (>=0) satisfies
the request (zero is greater than -1).<br>
<br>
I would not say it "ignores" it, just that it already is
greater or equal to the request.<br>
The current phrasing of
ByteArrayOutputStream.ensureCapacity uses the "holds at
least" phrasing.<br>
It would risky to change the implementation of
BAOS.ensureCapacity to not throw OOME on negative
minCapacity.<br>
<br>
Roger<br>
<br>
<br>
<div>On 1/6/26 1:30 PM, Daniel Gredler wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi Roger,</div>
<div><br>
</div>
<div>All points noted, thanks -- just wanted to
double check on this:</div>
<div><br>
</div>
<div>> I don't think you could call it
`ensureCapacity()` if it ignores the request.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Let me know your thoughts on this final point,
and I'll move forward with both the CSR and the
PR.</div>
<div><br>
</div>
<div>Thanks!</div>
<div><br>
</div>
<div>Daniel</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jan 6,
2026 at 3:54 PM Roger Riggs <<a href="mailto:roger.riggs@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">roger.riggs@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> Hi Daniel,<br>
<br>
I don't think you could call it
`ensureCapacity()` if it ignores the request.<br>
<br>
The limit is not specified, different VMs have
different overheads.<br>
<br>
The exception and message are appropriate:
"java.lang.OutOfMemoryError: Requested array
size exceeds VM limit "<br>
<br>
For negative arguments, an
IllegalArgumentException might be an improvement
in usability for developers.<br>
<br>
[2] 8258565 is closed as "will not fix" because
the memory limits are an implementation
parameter, not specified.<br>
<br>
Thanks, Roger<br>
<br>
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.<br>
<br>
<br>
<div>On 1/6/26 9:01 AM, Daniel Gredler wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi Roger,</div>
<div><br>
</div>
<div>Thanks for the feedback, I've created
an issue in JBS [1] and will create the PR
in the coming days.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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`.</div>
<div><br>
</div>
<div>Take care,</div>
<div><br>
</div>
<div>Daniel</div>
<div><br>
</div>
<div>[1] <a href="https://bugs.openjdk.org/browse/JDK-8374610" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8374610</a></div>
<div>[2] <a href="https://bugs.openjdk.org/browse/JDK-8258565" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8258565</a></div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon,
Jan 5, 2026 at 3:54 PM Roger Riggs <<a href="mailto:roger.riggs@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">roger.riggs@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi
Daniel,<br>
<br>
That seems reasonable, allowing control
over the timing of resizes.<br>
Making it public is sensible too.<br>
<br>
From a higher point of view, are you sure
you want to be working with <br>
ByteArrayOutputStream and not ByteBuffer
or Memory Segments? There are <br>
more performance possibilities with those
APIs.<br>
<br>
Regards, Roger<br>
<br>
<br>
On 1/5/26 7:15 AM, Daniel Gredler wrote:<br>
> Hi,<br>
><br>
> I was recently looking at subclassing
`ByteArrayOutputStream` in an <br>
> application so that I could add a
fast VarHandle-based <br>
> `writeLong(long)` method (writing 8
bytes to the byte array in one <br>
> go). The
internal `ByteArrayOutputStream` buffer is
protected, so no <br>
> issue there, but
`ensureCapacity(int)` is private rather
than <br>
> protected, and uses the internal
`ArraysSupport` class, so it's not <br>
> even easy to copy/paste as duplicate
code in the subclass. Similar <br>
> `ensureCapacity` methods in
`ArrayList` and `StringBuilder` are <br>
> public. Would a PR adjusting the
visibility of this method from <br>
> private to protected be accepted?<br>
><br>
> Take care,<br>
><br>
> Daniel<br>
><br>
><br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>