FloatingPointAssertionWithinEpsilonTest depends on default locale

[commonquail]

FloatingPointAssertionWithinEpsilonTest expresses locale agnostic checks, but FloatingPointAssertionWithinEpsilon is locale aware so the test fails in environments that don't use . as decimal separator.

Given

for lang in C.UTF-8 da_DK.UTF-8 ; do
    LANG=$lang mvn verify -pl core -am -Dsurefire.failIfNoSpecifiedTests=false -Dtest=FloatingPointAssertionWithinEpsilonTest
done

the second execution will fail with

[INFO] Running com.google.errorprone.bugpatterns.FloatingPointAssertionWithinEpsilonTest
[ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.201 s <<< FAILURE! - in com.google.errorprone.bugpatterns.FloatingPointAssertionWithinEpsilonTest
[ERROR] com.google.errorprone.bugpatterns.FloatingPointAssertionWithinEpsilonTest.positiveCase  Time elapsed: 0.138 s  <<< FAILURE!
Did not see an error on line 19 matching 6.0e-08. All errors:
/FloatingPointAssertionWithinEpsilonPositiveCases.java:19: warning: [FloatingPointAssertionWithinEpsilon] This fuzzy equality check is using a tolerance less than the gap to the next number (which is ~6,0e-08). You may want a less restrictive tolerance, or to assert equality.
    assertThat(1.0f).isWithin(1e-20f).of(1.0f);
                                        ^
    (see https://errorprone.info/bugpattern/FloatingPointAssertionWithinEpsilon)
  Did you mean 'assertThat(1.0f).isEqualTo(1.0f);'?

FloatingPointAssertionWithinEpsilon's use of default-locale String.format (heh) is consistent with Error Prone in general, so the error is probably that the test cases in question ignore the default locale, or alternatively that a specific default locale is assumed and unspecified.

[commonquail]

tyvm!