Why NumberFormat working different for openjdk@11 and openjdk@17?

Question

There is sample code (below). Result of execution is different for jdk@11 and jdk@17. Looks like white characters are different after formatting BigDecimal(1000) to String. Finally result looks the same - BUT, it is not the same String (compare bytes and Base64.encoded).

    import java.math.BigDecimal;
    import java.text.NumberFormat;
    import java.util.Base64;
    import java.util.Locale;

    public class NumberFormatTest {

        public static void main(String...args) {
            Locale locale = new Locale("fr", "FR");
            NumberFormat numberFormat = NumberFormat.getCurrencyInstance(locale);
            BigDecimal value = BigDecimal.valueOf(1000);

            String result = numberFormat.format(value); // <-- HERE!

            System.out.println(result);
            byte[] bytes = result.getBytes();
            for( int i=0; i<bytes.length; i++) {
                System.out.print(bytes[i]+", ");
            }
            System.out.println();
            System.out.println(Base64.getEncoder().encodeToString(bytes));
        }

    }

result for jdk@11 is different than for jdk@17

result for jdk@11:

1 000,00 €
49, -62, -96, 48, 48, 48, 44, 48, 48, -62, -96, -30, -126, -84, 
McKgMDAwLDAwwqDigqw=

result for jdk@17:

1 000,00 €
49, -30, -128, -81, 48, 48, 48, 44, 48, 48, -62, -96, -30, -126, -84, 
MeKArzAwMCwwMMKg4oKs

jdk@11:

openjdk version "11.0.12" 2021-07-20
OpenJDK Runtime Environment Homebrew (build 11.0.12+0)
OpenJDK 64-Bit Server VM Homebrew (build 11.0.12+0, mixed mode)

jdk@17:

openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment Homebrew (build 17.0.1+1)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.1+1, mixed mode, sharing)

System:

MacOS
Catalina 10.15.7

Is it expected behaviour?

Answer 1

Note that the difference between the two versions is that the the grouping separator (between the 1 and the 0 ) is U+00A0 (NO-BREAK SPACE) in JDK 11, and U+202F (NARROW NO-BREAK SPACE) in JDK 17.

This is the expected behaviour. See this bug report that was resolved as "not a problem".

From the discussions in the bug report:

CLDR has changed the grouping separator for French in v34, from U+00A0 to U+202F: https://www.unicode.org/cldr/charts/34/delta/fr.html#Symbols JDK has been based on v35.1 since [JDK 13] b21