On Tue, 17 Jan 2023 12:23:25 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> The choice of a `<p>` paragraph rather than `@apiNote` is for consistency >> with similar commentary paragraphs in the specs of `CASE_INSENSITIVE`, >> `UNICODE_CASE`, and `UNICODE_CHARACTER_CLASS`. >> >> I have no problems in using `@apiNote` instead, but then it would be better >> to apply the same for the other mentioned flags as well. > > Okay, I see your point and to use apiNote consistently would require > "converting" some of the existing text to apiNote too. > > I'm still mulling over Pattern.compile throwing OOME. An implNote is probably > the right category for this, in which case it can start with "In the the JDK > Reference Implementation ...". I assume the static Pattern.matches needs > same, and also Pattern.matcher for the lazy compilation case. There's no hard limit for the number of combining marks in the Unicode specification, even though in practice it never reaches the implementation limit. A high number of combining marks is thus more akin to a a resource exhaustion condition than to anything else, IMO. Even today, compilation of a pattern risks throwing an OOME anyway when trying to generate the permutations. Pre-emptively throwing an OOME just anticipates and extrapolates this behavior beyond the `int` limit of array lengths. Alternatively, compilation (greedy or lazy) could throw `PatternSyntaxException`, although there is not really something wrong with syntax. I'll add `@implNote` to the other methods you mention. ------------- PR: https://git.openjdk.org/jdk/pull/12027
