Question

When it comes to parsing numbers with decimal separators from string, Wicket’s BigDecimalConverter behaves differently than BigDecimal’s (String val) constructor.

Let’s try to parse a number with comma as the decimal separator using US locale. (I’m using Wicket 1.4.14 BTW.)

---

new BigDecimalConverter().convertToObject("1,3", Locale.US)
returns 13,

---

but

---

Locale.setDefault(Locale.US);
new BigDecimal("1,3")  

throws NumberFormatException.

---

Why doesn’t BigDecimalConverter behave the same way as BigDecimal in this case? The number “1,3” doesn’t make sense for the US locale.

Answer 1

The BigDecimal class implements its own validation algorithm on the input, which is throwing the NumberFormatException.

The reason why BigDecimalConverter is parsing 1,3 as 13 is that it is using a raw DecimalFormat behind the scenes. In AbstractNumberConverter.parse(), the getNumberFormat(locale) and parse() methods combination boils down to the following snippet, that takes Wicket out of the equation:

NumberFormat format = NumberFormat.getInstance(Locale.US);
format.setParseBigDecimal(true);
BigDecimal bd = format.parseObject("1,3");
System.out.println(bd.toString()); // Prints 13 !

UPDATE
The reason why DecimalFormat is ignoring the , character is because it is defined as the grouping separator in the DecimalFormatSymbols for the US locale.
It is permitted, and legal as it would be in 1,300.5.

In case you want to avoid converting 1,3 to 13, and throwing a invalid format conversion exception, you could override BigDecimalConverter.getNumberFormat(Locale) in order to modify the DecimalFormat to not use grouping, use a different grouping symbol, or use a more restrictive pattern. For instance:

TextField<BigDecimal> text = new TextField<BigDecimal>(id, model){
    @Override
    public IConverter getConverter(Class<?> type) {
        return new BigDecimalConverter() {
            @Override
            public NumberFormat getNumberFormat(Locale locale) {
                NumberFormat format = super.getNumberFormat(locale);
                format.setGroupingUsed(false);
                return format;
            }
        };
    }
};
text.setType(BigDecimal.class);

Note: Use the above example with caution, create a class for the Converter so it doesn’t get instantiated at each call of getConverter() and don’t modify the NumberFormat instance BigDecimalConverter.getNumberFormat() returns, it might be a global shared instance.

Just to add, this is the exact piece of code that’s ignoring the , character for being a group separator: DecimalFormat.subparse() branch in line 1522. With input of 1,3, the comma is ignored, being isGroupingUsed() true.