Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

This is an attempt to reopen bug 4350931.
That bug complained that the French thousands separator 
(when formatting numbers) does not print.  The bug was 
closed; it was claimed that the thousands separator is a space.

It is true that the separator is a space, but it is a special non-breaking 
space -- the character 0xA0.  This means that if the user in a UI types
a number with (normal) spaces, the Java formatting code will reject it 
with an error.

It's not even clear that this special space character will be displayed 
as such in a HTML client.  Certainly it will not occur to a user who 
sees an existing value that he needs to type a funny space character.

The following source code shown the spaces will cause the number
be rejected.

import java.text.*;
import java.util.Locale;

public class French {
  public static void main(String args []) {
    NumberFormat form = NumberFormat.getInstance(Locale.FRENCH);
    form.setGroupingUsed(true);
    String fmt = form.format(123456.789);

    System.out.println("Here is the formatted value:");
    for (int i = 0; i < fmt.length(); i++) {
      System.out.print((int) (fmt.charAt(i)));
      System.out.println(" " + fmt.charAt(i));
    }

    String fmtAsSpace = "123 456,789";
    System.out.println("About to parse " + fmtAsSpace);

    try {
      System.out.println(form.format(fmtAsSpace));
    } catch (Exception e) {
      System.out.println(e.getMessage());
    }
  }
}

Here is the output:

Here is the formatted value:
49 1
50 2
51 3
160 ?
52 4
53 5
54 6
44 ,
55 7
56 8
57 9
About to parse 123 456,789
Cannot format given Object as a Number
(Review ID: 132812) 
======================================================================

(1) Remove user's grouping separator (i.e. U+0020) in a String to be parsed.

    DecimalFormatSymbols dfs = new DecimalFormatSymbols(Locale.FRENCH);
    char groupingSeparator = dfs.getGroupingSeparator();
    if (groupingSeparator == '\u00a0') {
        fmtAsSpace = fmtAsSpace.replace(" ", "");
    }

(2) Replace user's grouping separator with the formatter's grouping seperator (U+00A0) if it's inconvenient to remove all spaces.

    DecimalFormatSymbols dfs = new DecimalFormatSymbols(Locale.FRENCH);
    char groupingSeparator = dfs.getGroupingSeparator();
    if (groupingSeparator == '\u00a0') {
        fmtAsSpace = fmtAsSpace.replaceAll(" (\\d)", groupingSeparator + "$1"); // or " (\\d\\d\\d)"
    }

Please note that there's no way to get a DecimalFormatSymbols from a NumberFormat. This example assumes that the default DecimalFormatSymbols is used in the NumberFormat implementation.

I guess what's really meant here is parsing - i.e., the line
      System.out.println(form.format(fmtAsSpace));
should be
      System.out.println(form.parse(fmtAsSpace));

With that, fmtAsSpace is parsed as 123, i.e., characters starting with the space are simply ignored.

This stems from the fact that parsing is designed to be able to extract pieces of formatted data from a text stream - e.g., the first part might just be the day component of a date string. Obviously, that's not what an application is looking for when it calls parse(String). It seems what the submitter is really requesting is a way to parse the entire string regardless of whether it uses regular or nonbreaking spaces.
  xxxxx@xxxxx   2001-10-03
I don't think there's any realistic way to fix this problem without breaking compatibility. The easiest workaround would be to remove all space characters in the string to be parsed. Please refer to Work Around. Please note that parse() doesn't require use of the grouping separator even setGroupingUsed(true) is called.
Posted Date : 2008-10-09 03:54:50.0

Hi, I am the submitter.  Your substitution of
parse() for format() is correct.
What I am really complaining about is the use
of the nonbreaking space, which introduces more
problems than it solves.

The groupingSeparatorCharacter int value is 160, not 32 
(regular space). This causes validation problems when user
input containing a space from text fields is passed into their 
document objects via insertString with the space character 
represented as 32 is compared to the grouping character 
from French locale which is 160. Validation fails all the time 
and there is no workaround. This needs to be fixed.

I just ran across this issue with the Finnish locale as well, which formats numbers in the same way as the French locale does. Too bad this is still unfixed as of 1.5. 

It is really annoying that when the user inputs numbers in a seemingly completely correct fashion (by pressing the spacebar for grouping separator), and then the input is cut at the first space by the parser... another issue is of course that a lot of people don't bother using the grouping separator in the first place, but the support for it must of course be there -- the software needs to be able to read its own output, even if the users didn't input 100% correct numbers.

Of course I can preprocess my input by removing all spaces prior to using NumberFormat, but this sort of locale-specific hackery sort of defeats the entire purpose of using NumberFormat in the first place...

This is also true for the Swedish locale. The formatted data is not usable for imports to for instance Excel.

This bug also happens in the Czech locale