[
https://issues.apache.org/jira/browse/TRINIDAD-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605468#action_12605468
]
Matthias Weßendorf commented on TRINIDAD-1124:
----------------------------------------------
Here are two BigDecimals:
-new java.math.BigDecimal(new Double(333.111).toString())
-new java.math.BigDecimal(new Double(333.111).doubleValue())
the last is "wrong" in the sense of why the bug was filed...
The Trinidad Converter *could* do something like this, at the end of its
getAsObject() method:
...
ValueExpression ve = component.getValueExpression("value");
if(ve != null &&
BigDecimal.class.isAssignableFrom(ve.getType(context.getELContext())))
{
return (new BigDecimal(num.toString()));
}
...
However, this is (very) expensive, to execute on every time the getAsObject()
from the NumberConverter is called. Since it always goes to the last guy, in
the expression.
> numberconverter has issue with bigdecimal
> -----------------------------------------
>
> Key: TRINIDAD-1124
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1124
> Project: MyFaces Trinidad
> Issue Type: Bug
> Reporter: Matthias Weßendorf
> Assignee: Matthias Weßendorf
>
> Due to a potential bug in BigDecimal there is a bug, when you use BigDecimal
> with a NumberConverter.
> Like
> <tr:inputText value="#{bean.number}" ...>
> <tr:convertNumber />
> </tr:inputText>
> For instance, when the entered value is "333.111" the actual stored value is
> 333.1109999999999899955582804977893829345703125
> There is a mathematic explanation for that in here:
> http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
