Consider the following test case:
This test case fails since the string "1 2" is parsed as number (int)12 using the ICU code. An equivalent testcase that uses the Java SE NumberFormat parser produces a number with value (int) 1 as expected.
Further experiments show that all spaces may be ignored by ICU. For example, Sun fails to parse " 1 2 " and leaves the parse position at 0, whereas ICU parses the whole string and consumes the spaces.
Tested with ICU4J-4.2.1
java spec says: If IntegerOnly is set, will stop at a decimal point (or equivalent; e.g., for rational numbers "1 2/3", will stop after the 1), It implies that blank space will be treated as decimal point. Though it is rather vague. I think ticket 7128 doesn’t follow the spec. We should fix it later.
This behavior is as designed. We already shipped DecimalFormat supporting the extended separator matching behavior in ICU4J 4.0 and 4.2. To support JDK compatible behavior, we need to provide a way to control the extended separator matching logic used in DecimalFormat implementation. I wrote a design note - http://site.icu-project.org/design/number-parsing/icu4j-number-parsing-problems - however, it looks we cannot get a conclusion soon. So I decided to introduce a configuration property to disable the extended separator matching via system property for now. We'll use a new ticket to discuss about API access for future releases.
It took a long time to locate the configuration property mentioned above. For others who have the same problem: The "fix" involves setting the com.ibm.icu.text.DecimalFormat.SkipExtendedSeparatorParsing ICU config flag to true.
Milestone 4.3.4 deleted