JDK-8189343 : Change of behavior of java.util.regex.Pattern between JDK 8 and JDK 9
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.regex
  • Affected Version: 9,10
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2017-10-15
  • Updated: 2021-04-01
  • Resolved: 2017-11-28
Related Reports
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)


A DESCRIPTION OF THE PROBLEM :
java.util.regex.Pattern behaves differently for pattern "[^x&&[^\n]]" and similar ones in JDK 8 and JDK 9 as shown in reproducer below. Seems that this change of behavior went unnoticed - at least I wasn't able to find any explicit mention of this in release notes and resolved tickets. Also seems that this was introduced by changes for JDK-6328855.

IMO description of java.util.regex.Pattern is not very clear about behavior in this and similar cases and anyway requires update.

REGRESSION.  Last worked in version 8u144

ADDITIONAL REGRESSION INFORMATION: 
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

Log of bisection of hg.openjdk.java.net/jdk10/master/ :

$ hg bisect --bad jdk-9+140
$ hg bisect --good jdk-9+110
Testing changeset 39088:69bb31538c06 (4725 changesets remaining, ~12 tests)

# test failed
$ hg bisect --bad
Testing changeset 38128:22391eb0c22d (2357 changesets remaining, ~11 tests)

# build failed
$ hg bisect --skip
Testing changeset 38127:2ab00cd4556e (2357 changesets remaining, ~11 tests)
$ hg bisect --skip
Testing changeset 37914:a2f43d835fa1 (2357 changesets remaining, ~11 tests)

# test failed
$ hg bisect --bad
Testing changeset 37302:cf820d974c75 (1183 changesets remaining, ~10 tests)

# build failed
$ hg bisect --skip
Testing changeset 37301:a936b4e01afb (1183 changesets remaining, ~10 tests)
$ hg bisect --skip
Testing changeset 37300:82e233a4a546 (1183 changesets remaining, ~10 tests)
$ hg bisect --skip
Testing changeset 37477:0ca0b7388bb6 (1183 changesets remaining, ~10 tests)
$ hg bisect --skip
Testing changeset 37299:db3b0d4c3bda (1183 changesets remaining, ~10 tests)
$ hg bisect --skip
Testing changeset 37298:8df0cc9da41e (1183 changesets remaining, ~10 tests)
$ hg bisect --skip
Testing changeset 37478:ef779fb991cf (1183 changesets remaining, ~10 tests)
$ hg bisect --skip
Testing changeset 37507:bade77e200d0 (1183 changesets remaining, ~10 tests)
$ hg bisect --skip
Testing changeset 37374:ee1b8619eddb (1183 changesets remaining, ~10 tests)
$ hg bisect --skip
Testing changeset 37508:3bf78337709d (1183 changesets remaining, ~10 tests)
$ hg bisect --skip
Testing changeset 37377:bd3b98a11a14 (1183 changesets remaining, ~10 tests)
$ hg bisect --skip
Testing changeset 37509:bdb5e37b92f9 (1183 changesets remaining, ~10 tests)
$ hg bisect --skip
Testing changeset 37510:cf066fe4531b (1183 changesets remaining, ~10 tests)
$ hg bisect --skip
Testing changeset 37511:2cd9b35e0eda (1183 changesets remaining, ~10 tests)
$ hg bisect --skip
Testing changeset 37380:55c2549714af (1183 changesets remaining, ~10 tests)

# test passed
$ hg bisect --good
Testing changeset 37646:84aba7335005 (534 changesets remaining, ~9 tests)
$ hg bisect --good
Testing changeset 37795:c5dc5ab60139 (267 changesets remaining, ~8 tests)

# build failed
$ hg bisect --skip
Testing changeset 37796:256c45c4af5d (267 changesets remaining, ~8 tests)
$ hg bisect --skip
Testing changeset 37794:7223f8ad31a5 (267 changesets remaining, ~8 tests)
$ hg bisect --skip
Testing changeset 37797:b84e375f071d (267 changesets remaining, ~8 tests)
$ hg bisect --skip
Testing changeset 37793:41844efbbcce (267 changesets remaining, ~8 tests)
$ hg bisect --skip
Testing changeset 37798:e1de34b6475c (267 changesets remaining, ~8 tests)
$ hg bisect --skip
Testing changeset 37777:08b7d4a71e11 (267 changesets remaining, ~8 tests)

# test passed
$ hg bisect --good
Testing changeset 37846:772743807917 (137 changesets remaining, ~7 tests)
$ hg bisect --good
Testing changeset 37894:3acc9608c162 (68 changesets remaining, ~6 tests)

# test failed
$ hg bisect --bad
Testing changeset 37877:dae28a12fb38 (34 changesets remaining, ~5 tests)

# test passed
$ hg bisect --good
Testing changeset 37885:5ac482a31fd5 (17 changesets remaining, ~4 tests)

# test failed
$ hg bisect --bad
Testing changeset 37881:fda31effa7b3 (8 changesets remaining, ~3 tests)

# test passed
$ hg bisect --good
Testing changeset 37883:e2acd0d8d716 (4 changesets remaining, ~2 tests)

# test failed
$ hg bisect --bad
Testing changeset 37882:e7f3cf12e739 (2 changesets remaining, ~1 tests)

$ hg bisect --bad
The first bad revision is:
changeset:   37882:e7f3cf12e739
user:        sherman
date:        Tue May 10 21:19:25 2016 -0700
summary:     6328855: String: Matches hangs at short and easy Strings containing \r \n

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and execute provided source file.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
no exception as was with JDK 8
ACTUAL -
Exception in thread "main" java.lang.AssertionError
        at Example.test(Example.java:11)
        at Example.main(Example.java:6)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
class Example {
  public static void main(String[] args) {
    String p = "[^x&&[^\n]]";
    test(p, "x", false);
    test(p, "y", true);
    test(p, "\n", false);
  }

  private static void test(String p, String i, boolean e) {
    if (java.util.regex.Pattern.compile(p).matcher(i).matches() != e) {
      throw new AssertionError();
    }
  }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Can be replaced by "[[^x]&&[^\n]]" or by "[^x\n]", whose behavior is the same in JDK 8 and JDK 9.

Or simply do not use weird regular expressions ;)


Comments
@see (5) http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction @see http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-June/006957.html
28-11-2017

it's probably the fix for JDK-6609854
28-11-2017

Issue is reproducible, to reproduce run the attached test case(Example.java): Results in different builds: JDK8u152 b16 - PASS JDK9 build 118 - PASS JDK9 build 119 - FAIL JDK9 build 181 - FAIL JDK10 build 27 - FAIL It looks like a regression introduced by task JDK-6328855, which is integrated in JDK9 build 119.
16-10-2017