-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
P4
-
Affects Version/s: 22
-
Component/s: core-libs
-
Fix Understood
When looking into something else, Ana [~amihalceanu] ran into a test failure in test/jdk/java/text/Format/NumberFormat/Bug4944439.java. Several test methods in that test fail on her local system with exceptions like:
18:47:58.418] STARTED Bug4944439::parseLongTest '[1] -9223372036854775808.00'
org.opentest4j.AssertionFailedError: DecimalFormat.parse("%s") did not return Long ==> Unexpected type, expected: <java.lang.Long> but was: <java.lang.Double>
at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at org.junit.jupiter.api.AssertInstanceOf.assertInstanceOf(AssertInstanceOf.java:49)
at org.junit.jupiter.api.AssertInstanceOf.assertInstanceOf(AssertInstanceOf.java:35)
at org.junit.jupiter.api.Assertions.assertInstanceOf(Assertions.java:3630)
at Bug4944439.parseLongTest(Bug4944439.java:73)
A bit of investigation reveals that the default locale on her system is "en_NL" which causes these failures.
Interestingly, the test seems to configure the default locale to Locale.US to avoid these issues, in its BeforeAll method:
// Save JVM default locale
private static final Locale savedLocale = Locale.getDefault();
private static final DecimalFormat df = new DecimalFormat();
// Set JVM default locale to US for testing
@BeforeAll
static void initAll() {
Locale.setDefault(Locale.US);
}
// Restore JVM default locale
@AfterAll
static void tearDownAll() {
Locale.setDefault(savedLocale);
}
However, notice that the DecimalFormat instance is already constructed as a final field before the default Locale is switched to Locale.US. So the DecimalFormat instance used in the test ends up using a non-US locale causing this failure.
This looks like an oversight in the test when some of these tests were converted to JUnit throughJDK-8317372 (it would be good to check if other tests in that changeset might have similar issue).
18:47:58.418] STARTED Bug4944439::parseLongTest '[1] -9223372036854775808.00'
org.opentest4j.AssertionFailedError: DecimalFormat.parse("%s") did not return Long ==> Unexpected type, expected: <java.lang.Long> but was: <java.lang.Double>
at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at org.junit.jupiter.api.AssertInstanceOf.assertInstanceOf(AssertInstanceOf.java:49)
at org.junit.jupiter.api.AssertInstanceOf.assertInstanceOf(AssertInstanceOf.java:35)
at org.junit.jupiter.api.Assertions.assertInstanceOf(Assertions.java:3630)
at Bug4944439.parseLongTest(Bug4944439.java:73)
A bit of investigation reveals that the default locale on her system is "en_NL" which causes these failures.
Interestingly, the test seems to configure the default locale to Locale.US to avoid these issues, in its BeforeAll method:
// Save JVM default locale
private static final Locale savedLocale = Locale.getDefault();
private static final DecimalFormat df = new DecimalFormat();
// Set JVM default locale to US for testing
@BeforeAll
static void initAll() {
Locale.setDefault(Locale.US);
}
// Restore JVM default locale
@AfterAll
static void tearDownAll() {
Locale.setDefault(savedLocale);
}
However, notice that the DecimalFormat instance is already constructed as a final field before the default Locale is switched to Locale.US. So the DecimalFormat instance used in the test ends up using a non-US locale causing this failure.
This looks like an oversight in the test when some of these tests were converted to JUnit through
- caused by
-
JDK-8317372 Refactor some NumberFormat tests to use JUnit
-
- Resolved
-
- relates to
-
JDK-8372624 Remove outdated locale saving in i18n tests
-
- Open
-
- links to
-
Review(master)
openjdk/jdk/28514