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 > >> > > >