RFR: 8241055: Regex Grapheme Matcher Performance Depends too much on Total Input Sequence Size

Hi, Any opinions on the attached patch or someone tempted to sponsor it? Regards, Philipp diff -r 84215fa115fc src/java.base/share/classes/java/util/regex/Grapheme.java --- a/src/java.base/share/classes/java/util/regex/Grapheme.java Fri Mar 20 17:37:52 2020 -0700 +++ b/src/java.base/share/classes

Re: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

Hi Naoto and everyone, There are almost as many occurrences of Locale.ROOT as Locale.US which made me wonder which one is more appropriately locale-independent and which is probably another topic and not actually relevant here because BreakIterator.getCharacterInstance is locale-agnostic as far as

Re: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable

Ok, thanks for explaining this. I hadn't realized the conversions were designed to work without a source type. I've removed the source type in the next revision: http://cr.openjdk.java.net/~jvernee/8241100/webrev.02/ Jorn On 21/03/2020 06:08, John Rose wrote: On Mar 20, 2020, at 10:49 AM, J

Re: RFR 8237599 : Greedy matching against supplementary chars fails to respect the region

Gentle ping. The webrev was rebased to accommodate recent changes in RegExTest.java. The fix is to handle an edge case situation, which is supposedly not too common. Nevertheless, I think, it is important to handle it correctly. Thanks in advance! Ivan On 1/22/20 8:23 PM, Ivan Gerasimov w