[
https://issues.apache.org/jira/browse/LANG-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495135#comment-13495135
]
Thomas Neidhart commented on LANG-693:
--------------------------------------
Maybe I was unclear, but the float part afterwards would not be needed anymore,
as this would never succeed.
Another idea would be to add something like this (pseudo-code)
{noformat}
//Must be a float,double,BigDec
boolean allZeros = isAllZeros(mant) && isAllZeros(exp);
try {
Float f = createFloat(str);
BigDecimal one = createBigDecimal(str);
BigDecimal two = new BigDecimal(f);
// check for loss of precision in the conversion
if (one.compareTo(two) == 0) {
....
} catch (NumberFormatException nfe) { // NOPMD
// ignore the bad number
}
{noformat}
Maybe the getPrecision() method from BigDecimal could be used too.
It is also a problem of definition, as a floating-point number can not always
precisely expressed in the related data types, so the question is how to define
when a float will be returned, and when a double.
That's why I put my original proposal to just assume a double in case of a
missing type qualifier, as this is the default in java anyway.
> Method createNumber from NumberUtils doesn't work for floating point numbers
> other than Float
> ---------------------------------------------------------------------------------------------
>
> Key: LANG-693
> URL: https://issues.apache.org/jira/browse/LANG-693
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
> Affects Versions: 2.6
> Reporter: Carlos Rego
> Priority: Minor
> Fix For: 3.x
>
>
> Method createNumber from NumberUtils is trying to parse a string with a
> floating point number always first as a Float, that will cause that if we
> send a string with a number that will need a Double or even a BigDecimal the
> number will be truncate to accommodate into the Float without an exception to
> be thrown, so in fact we will no be returning ever neither a Double nor a
> BigDecimal.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
