I took a look at PriorityBlockingQueue.

Part of converting to ArraysSupport involves deleting the local orphan
MAX_ARRAY_SIZE; that needs to be done.

---
It looks like
newCap > oldCap
is always true, so we should delete the test?
                 if (newCap > oldCap && queue == array)
---
In Pattern.java I see
+            throw new OutOfMemoryError("Requested array size exceeds
VM limit");

That wording doesn't seem useful to me - the use of an array is an
implementation detail, and the user didn't __request__ it.

Better seems the wording in ArraysSupport
            throw new OutOfMemoryError("Required array length too large");
but if we're going to the trouble of composing a custom detail
message, I'd try harder to find one meaningful to the user of the API,
something like "pattern too large"

On Wed, Jun 10, 2020 at 5:15 AM Jim Laskey <james.las...@oracle.com> wrote:
>
> Will push if no comments by EOB.
>
> > On Jun 8, 2020, at 2:22 PM, Jim Laskey <james.las...@oracle.com> wrote:
> >
> > Revised to use a consistent error message. Modified AbstractStringBuilder 
> > and PriorityBlockingQueue to use ArraysSupport.newLength(). Didn't modify 
> > ByteArrayChannel and UnsyncByteArrayOutputStream since those changes would 
> > require changes to module exporting.
> >
> > webrev: http://cr.openjdk.java.net/~jlaskey/8230744/webrev-03/index.html 
> > <http://cr.openjdk.java.net/~jlaskey/8230744/webrev-03/index.html>
> >
> >
> >> On Jun 3, 2020, at 11:24 AM, Jim Laskey <james.las...@oracle.com> wrote:
> >>
> >> It's not the goal or role of this bug to fix the wrongs of the past, 
> >> merely add error messages to the exceptions. I raised the discussion as an 
> >> issue. Clearly there is a correct path to follow. If you think more effort 
> >> is required then file a bug. :-)
> >>
> >> Cheers,
> >>
> >> -- Jim
> >>
> >>
> >>
> >>
> >>> On Jun 2, 2020, at 7:13 PM, Stuart Marks <stuart.ma...@oracle.com> wrote:
> >>>
> >>>
> >>>
> >>> On 6/2/20 6:52 AM, Jim Laskey wrote:
> >>>> Revised to reflect requested changes.
> >>>> http://cr.openjdk.java.net/~jlaskey/8230744/webrev-01/index.html 
> >>>> <http://cr.openjdk.java.net/~jlaskey/8230744/webrev-01/index.html>
> >>>
> >>> On this, if all you're doing is changing exception messages, then I don't 
> >>> care very much, modulo concerns about wording from others. If you start 
> >>> to get into changing the growth logic (like the Math.addExact stuff) then 
> >>> please see my message on the related thread, "Sometimes constraints are 
> >>> questionable."
> >>>
> >>> Thanks,
> >>>
> >>> s'marks
> >>
> >
>

Reply via email to