Name: nt126004 Date: 09/11/2002


FULL PRODUCT VERSION :
This is an API, bug it appears present in all JDKs I use.

java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)

java version "1.3.1_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_04-b02)
Java HotSpot(TM) Client VM (build 1.3.1_04-b02, mixed mode)


FULL OPERATING SYSTEM VERSION : Linux 2.4.17 , glibc 2.2.4, RH 7.1


ADDITIONAL OPERATING SYSTEMS : Win98. Almost certainly all
platforms, this is an API bug.



A DESCRIPTION OF THE PROBLEM :
When using NumberFormat there is a function called
setGroupingUsed. This is supposed to turn off the use of
grouping seperators. The API does not specify if this will
effect parsing, formatting or both. It effects both, and I
believe the API should clearly specify this; because it's
effect on parsing is nothing short of dangerous.

When setGroupingUsed is set to false, the parsing routines
apparently do not accept grouping seperators. This is a bit
unintuitive because the parsing routines are generally very
forgiving, and the API does not state that setGroupingUsed
will prohibit grouping seperators from being accepted during
parsing.

When grouping seperators are supplied in a number to be
parsed, the parsing routines do not throw a
ParsingException, or provide any other indication that the
number is invalid. Instead the parsing routines improperly
parse the number and return the incorrect result:

EG:
"3,500.00" will be parsed to "3"

This may be related to open bug 4208573.

If the parsing routines cannot be fixed easily/quickly etc.,
I would suggest a modification to the API docs to warn the
user of the effect of using the setGroupingUsed has on
parsing (that grouping seperators will not be accepted)



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Run above source code


EXPECTED VERSUS ACTUAL BEHAVIOR :
When setGroupingUsed is set to false, I would expect format
to return a number without the grouping seperator (,) in the
US locale. It does this correctly.

When it comes to parsing, I initially would not have
expected setGroupingUsed to have any effect on parsing. The
parsing routines are quite leanient, and I would expect that
they would still accept numbers with grouping seperators.
The API does not specify at all what effect setGroupingUsed
will take on the parsing routines.

If it is deemed appropriate that setGroupingUsed should
effect parsing as well, I would expect that the grouping
seperator would be an invalid character, and the number
would fail parsing with a ParseException.

Instead, the parsing is fully successful, however returns a
clearly errounous result. This is an extreemly dangerous
bug, because it will ultimately lead the application to
believe the number was parsed correctly, and store the
result. Clearly loosing valuable precision from the input,
without warning or exception to the application.

This is almost certainly related to JDC Bug#: 4208573 Which
has been inprogress since java 1.2. This case described in
this bug is a much more serious problem then the case
described in 4208573 where they describe "0fdeugfuwefwe0"
being parsed without error.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No exceptions are thrown, and the number is misparsed.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.text.*;
import java.util.*;

public class BadParse {
public static void main(String[] s) {
NumberFormat formatNumber;
Locale locale = Locale.US;
formatNumber=NumberFormat.getNumberInstance(locale);
formatNumber.setGroupingUsed(true);
System.out.print("Parsing \"3,523.23\" with grouping on: ");
try {
System.out.println(formatNumber.parse("3,523.23"));
} catch (ParseException e) {
System.out.println("Parse exception parsing with grouping on");
}
System.out.println("Formatting \"3,523.23\" with grouping on:
"+formatNumber.format(3523.23)+"\n");

formatNumber.setGroupingUsed(false);
System.out.print("Parsing \"3,523.23\" with grouping off: ");
try {
System.out.println(formatNumber.parse("3,523.23"));
} catch (ParseException e) {
System.out.println("Parse exception parsing with grouping on");
}
System.out.println("Formatting \"3,523.23\" with grouping off:
"+formatNumber.format(3523.23)+"\n");


//WORKAROUND

formatNumber.setGroupingUsed(true);
((DecimalFormat)formatNumber).setGroupingSize(0);
System.out.print("Parsing \"3,523.23\" with grouping on, and grouping size 0: ");
try {
System.out.println(formatNumber.parse("3,523.23"));
} catch (ParseException e) {
System.out.println("Parse exception parsing with grouping on");
}
System.out.println("Formatting \"3,523.23\" with grouping on, and grouping size 0:
"+formatNumber.format(3523.23)+"\n");

}
}

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

CUSTOMER WORKAROUND :
Use setGroupingSize(0), as seen in the source code above.

Although setGroupingSize(0) is not documented what it will
do in the case where it is set to zero, it appears to work.
(Review ID: 159346)
======================================================================