RFR: 8354490: Pattern.CANON_EQ causes a pattern to not match a string with a UNICODE variation

[Xueming Shen]

The root cause is an off-by-one bug introduced in an old change we made years ago for Pattern.CANON_EQ.
See https://cr.openjdk.org/~sherman/regexCE/Note.txt for background info.

As described in the writeup above the basic logic of the change is to:

**generate the permutations, create the alternation and then put it appropriately into the character class (logically), we now use a special "Node", the NFCCharProperty to do the matching work. The NFCCharProperty tries to match a grapheme cluster at a time (nfc greedly, then backtrack) against the character class.**

It appears we have a off-by-one bug in the backtrack boundary condition check, when it backtracking to the position 'after' the base(main) character (in case where the resulting 'nfc' string is not a **single character'** string /not match). In such cases, we still need to match/compare the base character against the _predicate_ to find the potential match. 

For example in the reported scenario, the target string contains the pair of **u+2764** (emoji) + **u+fe0f** (variation selector/emoji_component). The boundary edge j = Grapheme.nextBoundary() starts at **2** (after u+fe0f), then it backtracks to 1. The current boundary check implementation incorrectly exits here because 0 + 1 < 1 fails, which is incorrect. 

This emoji pair should match correctly, s showed below


jshell> var p = Pattern.compile("\\p{IsEmoji}\\p{IsEmoji_Component}", Pattern.CANON_EQ);
p ==> \p{IsEmoji}\p{IsEmoji_Component}

jshell> p.matcher("\u2764\ufe0f").matches();
$53 ==> true


or


jshell> var p = Pattern.compile("\\p{IsEmoji}", Pattern.CANON_EQ);
p ==> \p{IsEmoji}

jshell> p.matcher("\u2764\ufe0f").find();
$55 ==> true


This bug is not limited to the emoji + variation selector pairs (which don't 'nfc' into a single character, even are treated as a single grapheme cluster). It also impacts cases involing dangling or unmatched combining character(s). For example, the following should work/match/find, even in Pattern.CANON_EQ mode.



jshell> p = Pattern.compile("\\p{IsGreek}\\p{IsAlphabetic}", Pattern.CANON_EQ);
p ==> \p{IsGreek}\p{IsAlphabetic}

jshell> p.matcher("\u1f80\u0345").matches();
$57 ==> true

jshell> p = Pattern.compile("[\\p{IsAlphabetic}]*", Pattern.CANON_EQ);
p ==> [\p{IsAlphabetic}]*

jshell> p.matcher("\u1f80\u0345").matches();
$59 ==> true


**note:** the grapheme boundary is not necessary the same as the resulting nfc boundary.

-------------

Commit messages:
 - 8354490: Pattern.CANON_EQ causes a pattern to not match a string with a UNICODE variation

Changes: https://git.openjdk.org/jdk/pull/25986/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25986&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354490
  Stats: 19 lines in 2 files changed: 15 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25986/head:pull/25986

PR: https://git.openjdk.org/jdk/pull/25986