JDK-8131041 : Garbage in output of DecimalFormat
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: linux
  • CPU: x86
  • Submitted: 2015-07-10
  • Updated: 2015-07-13
  • Resolved: 2015-07-13
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :


A DESCRIPTION OF THE PROBLEM :
$ java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

$ javac Example.java

$ LC_ALL=en_US.UTF-8 java Example
[49, 48, 48, 32, 37]

$ java -version
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b72)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b72, mixed mode)

$ LC_ALL=en_US.UTF-8 java Example
[49, 48, 48, -62, -96, 37]


REGRESSION.  Last worked in version 8u45


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.Arrays;
import java.util.Locale;
import java.text.DecimalFormat;
import java.text.NumberFormat;

public class Example {
  public static void main(String[] args) {
    NumberFormat f = DecimalFormat.getPercentInstance(Locale.FRENCH);
    System.out.println(Arrays.toString(f.format(1).getBytes()));
  }
}

---------- END SOURCE ----------


Comments
With the integration of JEP 252 to JDK9, CLDR locale data is now the default locale data, which is different from the legacy locale data in JDK8 and prior. If the submitter wants to work around this, they will need to use the legacy locale data explicitly by specifying "java.locale.providers" system property with "JRE,SPI".
13-07-2015

CLDR locale data uses U+00A0 NO-BREAK SPACE between digits and '%', while the legacy locale data uses the regular space.
13-07-2015

1. Run the attached example (Example.java) 2. Checked this for JDK 8u45, 8u60 ea b23, 9 ea b72. 3. Ouptput with (JDK 8u45): > java Example [49, 48, 48, 32, 37] (9 ea b72): > java Example [49, 48, 48, -96, 37] 4. This issue is reproducible with JDK 9 ea b72 as reported by the submitter.
13-07-2015