Why does \R behave differently in regular expressions between Java 8 and Java 9?

后端 未结 2 1451
不知归路
不知归路 2021-02-02 04:44

The following code compiles in both Java 8 & 9, but behaves differently.

class Simple {
    static String sample = \         


        
相关标签:
2条回答
  • 2021-02-02 05:39

    It was a bug in Java 8 and it got fixed: JDK-8176029 : "Linebreak matcher is not equivalent to the pattern as stated in javadoc".

    Also see: Java-8 regex negative lookbehind with `\R`

    0 讨论(0)
  • 2021-02-02 05:46

    The Java documentation is out of conformance with the Unicode Standard. The Javadoc mistates what \R is supposed to match. It reads:

    \R Any Unicode linebreak sequence, is equivalent to \u000D\u000A|[\u000A\u000B\u000C\u000D\u0085\u2028\u2029]

    That Java documentation is buggy. In its section on R1.6 Line Breaks, Unicode Technical Standard #18 on Regular Expressions clearly states:

    It is strongly recommended that there be a regular expression meta-character, such as "\R", for matching all line ending characters and sequences listed above (for example, in #1). This would correspond to something equivalent to the following expression. That expression is slightly complicated by the need to avoid backup.

     (?:\u{D A}|(?!\u{D A})[\u{A}-\u{D}\u{85}\u{2028}\u{2029}]
    

    In other words, it can only match a two code-point CR+LF (carriage return + linefeed) sequence or else a single code-point from that set provided that it is not just a carriage return alone that is then followed by a linefeed. That’s because it is not allowed to back up. CRLF must be atomic for \R to function properly.

    So Java 9 no longer conforms to what R1.6 strongly recommends. Moreover, it is now doing something that it was supposed to NOT do, and did not do, in Java 8.

    Looks like it's time for me to give Sherman (read: Xueming Shen) a holler again. I've worked with him before on these nitty-gritty matters of formal conformance.

    0 讨论(0)
提交回复
热议问题