[
https://issues.apache.org/jira/browse/WICKET-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870805#action_12870805
]
Pedro Santos commented on WICKET-2878:
--------------------------------------
"AbstractDecimalConvert calls setParseBigDecimal(true) for all DecimalFormat's.
"
Actually he calls setParseBigDecimal(true) for all DecimalFormat's created by
the newNumberFormat implementation, I can provide an test case where I have an
setted number format. Is this test case valid?
The AbstractDecimalConvert has public API for both strategies, user can
implement the newNumberFormat method, or invoke setNumberFormat. Isn't it an
prolix API?
> 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.
