Why does String.replaceAll() work differently in Java 8 from Java 9?












28















Why does this code output 02 in java-8 but o2 in java-9 or above?



"o2".replaceAll("([oO])([^[0-9-]])", "0$2")









share|improve this question




















  • 7





    A simplification of the code that still shows the behaviour : Pattern.matches("[^[x]]", "x") returns true with JDK8 and false with JDK9+.

    – Aaron
    9 hours ago


















28















Why does this code output 02 in java-8 but o2 in java-9 or above?



"o2".replaceAll("([oO])([^[0-9-]])", "0$2")









share|improve this question




















  • 7





    A simplification of the code that still shows the behaviour : Pattern.matches("[^[x]]", "x") returns true with JDK8 and false with JDK9+.

    – Aaron
    9 hours ago
















28












28








28


7






Why does this code output 02 in java-8 but o2 in java-9 or above?



"o2".replaceAll("([oO])([^[0-9-]])", "0$2")









share|improve this question
















Why does this code output 02 in java-8 but o2 in java-9 or above?



"o2".replaceAll("([oO])([^[0-9-]])", "0$2")






java regex string java-8 java-9






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 8 hours ago









Boann

37.1k1290121




37.1k1290121










asked 9 hours ago









Fuyang LiuFuyang Liu

592417




592417








  • 7





    A simplification of the code that still shows the behaviour : Pattern.matches("[^[x]]", "x") returns true with JDK8 and false with JDK9+.

    – Aaron
    9 hours ago
















  • 7





    A simplification of the code that still shows the behaviour : Pattern.matches("[^[x]]", "x") returns true with JDK8 and false with JDK9+.

    – Aaron
    9 hours ago










7




7





A simplification of the code that still shows the behaviour : Pattern.matches("[^[x]]", "x") returns true with JDK8 and false with JDK9+.

– Aaron
9 hours ago







A simplification of the code that still shows the behaviour : Pattern.matches("[^[x]]", "x") returns true with JDK8 and false with JDK9+.

– Aaron
9 hours ago














1 Answer
1






active

oldest

votes


















35














Most likely due to JDK-6609854 and JDK-8189343 which reported negative nested character classes handling (in your example [^[0-9-]]). This behavior was fixed in 9 and 10, but fix was not backported to 8. The bug for Java 8 is explained as:




In Java, the negation does not apply to anything appearing in
nested [brackets]



So [^c] does not match "c", as you would expect.



[^[c]] does match "c". Not what I would expect.



[[^c]] does not match "c"



The same holds true for ranges or property expressions - if they're
inside brackets, a negation at an out level does not affect them.



[^a-z] is opposite from [^[a-z]]







share|improve this answer





















  • 6





    You can't prove the regex does not match the string at regex101, it does not support character class union. In PCRE, [^[0-9-]] matches a char that is not [, digit and - and then a ].

    – Wiktor Stribiżew
    9 hours ago








  • 1





    @WiktorStribiżew removed, thanks. Would you suggest some other online tool that supports them?

    – Karol Dowbecki
    9 hours ago








  • 3





    Use RegexPlanet

    – Wiktor Stribiżew
    9 hours ago






  • 9





    In case it's not obvious -- the OP can fix this inconsistency by changing [^[0-9-]] to [^0-9-].

    – ruakh
    9 hours ago











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54946363%2fwhy-does-string-replaceall-work-differently-in-java-8-from-java-9%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









35














Most likely due to JDK-6609854 and JDK-8189343 which reported negative nested character classes handling (in your example [^[0-9-]]). This behavior was fixed in 9 and 10, but fix was not backported to 8. The bug for Java 8 is explained as:




In Java, the negation does not apply to anything appearing in
nested [brackets]



So [^c] does not match "c", as you would expect.



[^[c]] does match "c". Not what I would expect.



[[^c]] does not match "c"



The same holds true for ranges or property expressions - if they're
inside brackets, a negation at an out level does not affect them.



[^a-z] is opposite from [^[a-z]]







share|improve this answer





















  • 6





    You can't prove the regex does not match the string at regex101, it does not support character class union. In PCRE, [^[0-9-]] matches a char that is not [, digit and - and then a ].

    – Wiktor Stribiżew
    9 hours ago








  • 1





    @WiktorStribiżew removed, thanks. Would you suggest some other online tool that supports them?

    – Karol Dowbecki
    9 hours ago








  • 3





    Use RegexPlanet

    – Wiktor Stribiżew
    9 hours ago






  • 9





    In case it's not obvious -- the OP can fix this inconsistency by changing [^[0-9-]] to [^0-9-].

    – ruakh
    9 hours ago
















35














Most likely due to JDK-6609854 and JDK-8189343 which reported negative nested character classes handling (in your example [^[0-9-]]). This behavior was fixed in 9 and 10, but fix was not backported to 8. The bug for Java 8 is explained as:




In Java, the negation does not apply to anything appearing in
nested [brackets]



So [^c] does not match "c", as you would expect.



[^[c]] does match "c". Not what I would expect.



[[^c]] does not match "c"



The same holds true for ranges or property expressions - if they're
inside brackets, a negation at an out level does not affect them.



[^a-z] is opposite from [^[a-z]]







share|improve this answer





















  • 6





    You can't prove the regex does not match the string at regex101, it does not support character class union. In PCRE, [^[0-9-]] matches a char that is not [, digit and - and then a ].

    – Wiktor Stribiżew
    9 hours ago








  • 1





    @WiktorStribiżew removed, thanks. Would you suggest some other online tool that supports them?

    – Karol Dowbecki
    9 hours ago








  • 3





    Use RegexPlanet

    – Wiktor Stribiżew
    9 hours ago






  • 9





    In case it's not obvious -- the OP can fix this inconsistency by changing [^[0-9-]] to [^0-9-].

    – ruakh
    9 hours ago














35












35








35







Most likely due to JDK-6609854 and JDK-8189343 which reported negative nested character classes handling (in your example [^[0-9-]]). This behavior was fixed in 9 and 10, but fix was not backported to 8. The bug for Java 8 is explained as:




In Java, the negation does not apply to anything appearing in
nested [brackets]



So [^c] does not match "c", as you would expect.



[^[c]] does match "c". Not what I would expect.



[[^c]] does not match "c"



The same holds true for ranges or property expressions - if they're
inside brackets, a negation at an out level does not affect them.



[^a-z] is opposite from [^[a-z]]







share|improve this answer















Most likely due to JDK-6609854 and JDK-8189343 which reported negative nested character classes handling (in your example [^[0-9-]]). This behavior was fixed in 9 and 10, but fix was not backported to 8. The bug for Java 8 is explained as:




In Java, the negation does not apply to anything appearing in
nested [brackets]



So [^c] does not match "c", as you would expect.



[^[c]] does match "c". Not what I would expect.



[[^c]] does not match "c"



The same holds true for ranges or property expressions - if they're
inside brackets, a negation at an out level does not affect them.



[^a-z] is opposite from [^[a-z]]








share|improve this answer














share|improve this answer



share|improve this answer








edited 5 hours ago

























answered 9 hours ago









Karol DowbeckiKarol Dowbecki

22.6k93455




22.6k93455








  • 6





    You can't prove the regex does not match the string at regex101, it does not support character class union. In PCRE, [^[0-9-]] matches a char that is not [, digit and - and then a ].

    – Wiktor Stribiżew
    9 hours ago








  • 1





    @WiktorStribiżew removed, thanks. Would you suggest some other online tool that supports them?

    – Karol Dowbecki
    9 hours ago








  • 3





    Use RegexPlanet

    – Wiktor Stribiżew
    9 hours ago






  • 9





    In case it's not obvious -- the OP can fix this inconsistency by changing [^[0-9-]] to [^0-9-].

    – ruakh
    9 hours ago














  • 6





    You can't prove the regex does not match the string at regex101, it does not support character class union. In PCRE, [^[0-9-]] matches a char that is not [, digit and - and then a ].

    – Wiktor Stribiżew
    9 hours ago








  • 1





    @WiktorStribiżew removed, thanks. Would you suggest some other online tool that supports them?

    – Karol Dowbecki
    9 hours ago








  • 3





    Use RegexPlanet

    – Wiktor Stribiżew
    9 hours ago






  • 9





    In case it's not obvious -- the OP can fix this inconsistency by changing [^[0-9-]] to [^0-9-].

    – ruakh
    9 hours ago








6




6





You can't prove the regex does not match the string at regex101, it does not support character class union. In PCRE, [^[0-9-]] matches a char that is not [, digit and - and then a ].

– Wiktor Stribiżew
9 hours ago







You can't prove the regex does not match the string at regex101, it does not support character class union. In PCRE, [^[0-9-]] matches a char that is not [, digit and - and then a ].

– Wiktor Stribiżew
9 hours ago






1




1





@WiktorStribiżew removed, thanks. Would you suggest some other online tool that supports them?

– Karol Dowbecki
9 hours ago







@WiktorStribiżew removed, thanks. Would you suggest some other online tool that supports them?

– Karol Dowbecki
9 hours ago






3




3





Use RegexPlanet

– Wiktor Stribiżew
9 hours ago





Use RegexPlanet

– Wiktor Stribiżew
9 hours ago




9




9





In case it's not obvious -- the OP can fix this inconsistency by changing [^[0-9-]] to [^0-9-].

– ruakh
9 hours ago





In case it's not obvious -- the OP can fix this inconsistency by changing [^[0-9-]] to [^0-9-].

– ruakh
9 hours ago




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54946363%2fwhy-does-string-replaceall-work-differently-in-java-8-from-java-9%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown