Bug4944439 does not enforce locale correctly

XMLWordPrintable

    • b27

        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 through JDK-8317372 (it would be good to check if other tests in that changeset might have similar issue).


              Assignee:
              Justin Lu
              Reporter:
              Jaikiran Pai
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: