Problems with convertNumber and Double values

Question

I've serious troubles using convertNumber with Double data in input fields.
While output formatting works fine, the outputted string fails to be converted back - I get conversion errors.
So the value that is written to the input field generates a conversion error being submitted! This is not good practice!
I've found out the following: (I use german locale, so following examples containing ',' means decimal point)
<f:convertNumber pattern="##0.00" />generates the right output, eg. for Double(20.50) - "20,50", but this value ("20,50") will not be parsed using the above pattern! Only values with non zero last minimum fractional digit (eg "20,51", "20,59", ... ) will be parsed!
In addition, the above pattern doesn't parse numberstrings that don't contain all significant digits.
For example an input of "20" will not be parsed to "20.00"!
Maybe this is not the right forum for that problem, since i think this is a general java formatting problem (?).
But as the problem arised by using the convertNumber tag and acting like this on numeric input fields is not very comfortable, I liked to post this here. Maybe someone can give me some advice?

Answer 1

I also have found this problem, except that in my experience it is the decimal part that must be non-zero, not just the last digit of the decimal part. So with a pattern of "0.00" the string "1.50" (one and a half) will be accepted whereas the string "1.00" will not.
My guess (just a guess) is that it is related to the documented behaviour of the DecimalFormat object when it parses a number. According to the documentation:
The most economical subclass that can represent the number given by the string is chosen. Most integer values are returned as Long objects, no matter how they are written: "17" and "17.000" both parse to Long(17). Values that cannot fit into a Long are returned as Doubles. This includes values with a fractional part, infinite values, NaN, and the value -0.0. DecimalFormat does not decide whether to return a Double or a Long based on the presence of a decimal separator in the source string. Doing so would prevent integers that overflow the mantissa of a double, such as "10,000,000,000,000,000.00", from being parsed accurately. Currently, the only classes that parse returns are Long and Double, but callers should not rely on this. Callers may use the Number methods doubleValue, longValue, etc., to obtain the type they want.
Which means that "1.50" will be returned as a Double while "1.00" will be returned as a Long. Perhaps there is then a class-cast exception whie trying to use this value?
If this is indeed the problem, the solution is to use the getDouble() method of the parsed Number to create the Double to be returned, but this is for the implementer to do - not the user!