[
https://issues.apache.org/jira/browse/LANG-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025161#comment-13025161
]
Sebb edited comment on LANG-693 at 4/26/11 10:29 AM:
-----------------------------------------------------
I can confirm that "0.9090909090909091" is returned as a float 0.90909094.
Whether this is wrong is a different matter. The Javadoc says:
{quote}
Turns a string value into a java.lang.Number.
First, the value is examined for a type qualifier on the end
('f','F','d','D','l','L'). If it is found, it starts trying to create
successively larger types from the type specified until one is found that can
represent the value.
If a type specifier is not found, it will check for a decimal point and then
try successively larger types from Integer to BigInteger and from Float to
BigDecimal.
{quote}
The second paragraph does not specifically say that the code will return the
"best" match, nor does the 3rd para. It's not clear to me whether the method
was ever intended to return a "best" match (for some definintion of best). If
such behaviour is intended, then the Javadoc needs to be clarified, and the
code changed accordingly.
Note that the test of Double.MAX_VALUE works because this is converted to
Float.INFINITY.
Non-infinite values are rounded by Float.valueOf(String) to the nearest value,
so are never checked as doubles.
was (Author: [email protected]):
I can confirm that "0.9090909090909091" is returned as a float 0.90909094.
Whether this is wrong is a different matter. The Javadoc says:
{quote}
Turns a string value into a java.lang.Number.
First, the value is examined for a type qualifier on the end
('f','F','d','D','l','L'). If it is found, it starts trying to create
successively larger types from the type specified until one is found that can
represent the value.
If a type specifier is not found, it will check for a decimal point and then
try successively larger types from Integer to BigInteger and from Float to
BigDecimal.
{quote}
> 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
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
