[
https://issues.apache.org/jira/browse/WICKET-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870810#action_12870810
]
Juergen Donnerstag commented on WICKET-2878:
--------------------------------------------
I agree. I changed my local version to
@Override
public NumberFormat getNumberFormat(Locale locale)
{
NumberFormat numberFormat = numberFormats.get(locale);
if (numberFormat == null)
{
setNumberFormat(locale, newNumberFormat(locale));
}
return (NumberFormat)numberFormat.clone();
}
public final void setNumberFormat(final Locale locale, final
NumberFormat numberFormat)
{
if (numberFormat instanceof DecimalFormat)
{
((DecimalFormat)numberFormat).setParseBigDecimal(true);
}
numberFormats.put(locale, numberFormat);
}
That way we keep the API (can not change it in 1.4 anyway), but make sure
setParseBigDecimal(true) gets called.
> 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.
