SaveParticipantTest.testFormatChange* failed with additional whitespace

[jukzi]

SaveParticipantTest

4 fails in https://download.eclipse.org/eclipse/downloads/drops4/I20240608-0320/testresults/html/org.eclipse.jdt.ui.tests_ep433I-unit-mac64-java17_macosx.cocoa.x86_64_17.html
for example:

expected:<... { String s [= (String) ]o; } }> but was:<... { String s [ = (String)]o; } }>

org.junit.ComparisonFailure: expected:<... {
String s [= (String) ]o;
}
}> but was:<... {
String s [ = (String)]o;
}
}>
at org.junit.Assert.assertEquals(Assert.java:117)
at org.junit.Assert.assertEquals(Assert.java:146)
at org.eclipse.jdt.ui.tests.quickfix.SaveParticipantTest.testFormatChanges01(SaveParticipantTest.java:152)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)

[jukzi]

Locally randomly reproducible sometimes on various test methods. examples:

[jukzi]

again on mac:
https://download.eclipse.org/eclipse/downloads/drops4/I20240619-1800/testresults/html/org.eclipse.jdt.ui.tests_ep433I-unit-mac64-java17_macosx.cocoa.x86_64_17.html

[jukzi]

duplicate: #79 (also only mac)

[jukzi]

single test fail on linux:
https://download.eclipse.org/eclipse/downloads/drops4/I20240619-1800/testresults/html/org.eclipse.jdt.ui.tests_ep433I-unit-cen64-gtk3-java21_linux.gtk.x86_64_21.html

expected:<...* A block comment on[] two lines */ ...> but was:<...* A block comment on[ * ] two lines */ ...>

org.junit.ComparisonFailure: expected:<...* A block comment on[] two lines
*/

...> but was:<...* A block comment on[
* ] two lines
*/

...>
at org.junit.Assert.assertEquals(Assert.java:117)
at org.junit.Assert.assertEquals(Assert.java:146)
at org.eclipse.jdt.ui.tests.quickfix.SaveParticipantTest.testBug232768_2(SaveParticipantTest.java:790)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)

[carstenartur]

I think that is an old one. A number of reasons are possible. One could be that the formatting and compiler settings data structure gets duplicated in some situations. So working on a copy in some threads is not thread save. When changes are applied at runtime the question is which set of options is changed. That is a bug in jdt core. That is from the top of my head - could be in the meantime things have been improved. And then there was an issue with the undo not sure if related. I think in one of the junit tests you might still find a sleep to stabilize results.