[
https://issues.apache.org/jira/browse/LANG-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15397398#comment-15397398
]
Rob Tompkins edited comment on LANG-1040 at 7/28/16 11:21 AM:
--------------------------------------------------------------
There seems to be clear inconsistency between {{NumberUtils.createNumber(final
String val)}} and {{NumberUtils.isNumber(final String str)}}. I agree here that
the javadoc should be clarified as to what {{isNumber}} should return, but
either way it feels like there should be consistency. Sebb, do you have any
thoughts here?
Specifically I was looking at LANG-1038 which seems to point out such
inconsistencies, specifically if you add
{code:java}
compareIsNumberWithCreateNumber("+2",false);
{code}
in {{NumberUtilsTest.testIsNumber()}}.
Regardless, I would like to try to fix this up, so I'll try to clarify while
adhering as closely as possible to the java standards here.
was (Author: chtompki):
There seems to be clear inconsistency between NumberUtils.createNumber(final
String val) and NumberUtils.isNumber(final String str). I agree here that the
javadoc should be clarified as to what isNumber should return, but either way
it feels like there should be consistency. Sebb, do you have any thoughts
here?
Specifically I was looking at LANG-1038 which seems to point out such
inconsistencies, specifically if you add
{code:java}
compareIsNumberWithCreateNumber("+2",false);
{code}
in {{NumberUtilsTest.testIsNumber()}}.
Regardless, I would like to try to fix this up, so I'll try to clarify while
adhering as closely as possible to the java standards here.
> Javadoc for NumberUtils.isNumber() are not clear enough
> -------------------------------------------------------
>
> Key: LANG-1040
> URL: https://issues.apache.org/jira/browse/LANG-1040
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
> Affects Versions: 3.3.2
> Reporter: Duncan Jones
> Fix For: Discussion
>
>
> The Javadocs for {{NumberUtils.isNumber()}} do not clearly define what a
> valid number is. The current trunk documentation states:
> {quote}Checks whether the String a valid Java number.
> Valid numbers include hexadecimal marked with the 0x or 0X qualifier, octal
> numbers, scientific notation and numbers marked with a type qualifier (e.g.
> 123L).
> Non-hexadecimal strings beginning with a leading zero are treated as octal
> values. Thus the string 09 will return false, since 9 is not a valid octal
> value. However, numbers beginning with 0. are treated as decimal.
> Null and empty String will return false.{quote}
> In other Jira issues, I've seen people suggest that a number if valid if it
> can be used when assigning to a suitable Java type. E.g. {{"FOO"}} is a valid
> number if {{long x = FOO}} is valid (where {{long}} might be another numeric
> type). If this is the case, we should state it.
> Alternatively, the definition could be in terms of what is accepted by
> {{createNumber()}}.
> Or we define exactly what we accept by specifying a grammar in the Javadocs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
