[
https://issues.apache.org/jira/browse/WICKET-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870783#action_12870783
]
Juergen Donnerstag commented on WICKET-2878:
--------------------------------------------
Do you have a testcase where this happens? Since AbstractDecimalConvert calls
setParseBigDecimal(true) for all DecimalFormat's. And because of that parse()
insight BigDecimalConverter.convertToObject() returns already a BigDecimal
except for NaN and INFINITE etc. I couldn't find any usecase which returns a
Double.
So, though I agree to change BCD.convertToObject, it'll not change anything,
except you can provide a valid testcase.
Juergen
> BigDecimalConverter improvement
> -------------------------------
>
> Key: WICKET-2878
> URL: https://issues.apache.org/jira/browse/WICKET-2878
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.8
> Reporter: Pedro Santos
>
> I was having problems comparing values returned by the user input into some
> form fields of type BigDecimal. Looking for the problem, I notes that the
> BigDecimalConverter was passing double values as parameter to BigDecimal
> constructor. According with its doc:
> "he results of this constructor can be somewhat unpredictable. One might
> assume that writing new BigDecimal(0.1) in Java creates a BigDecimal which is
> exactly equal to 0.1 (an unscaled value of 1, with a scale of 1), but it is
> actually equal to 0.1000000000000000055511151231257827021181583404541015625.
> This is because 0.1 cannot be represented exactly as a double (or, for that
> matter, as a binary fraction of any finite length). Thus, the value that is
> being passed in to the constructor is not exactly equal to 0.1, appearances
> notwithstanding. "
> "The String constructor, on the other hand, is perfectly predictable: writing
> new BigDecimal("0.1") creates a BigDecimal which is exactly equal to 0.1, as
> one would expect. Therefore, it is generally recommended that the String
> constructor be used in preference to this one. "
> Can BigDecimalConverter use the valueOf method of the BigDecimal API or
> String constructor to create those objects from double values? IMO giving
> preference to those options we are improving the converter, since the value
> will to be predictable
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
