You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Rob Tompkins (JIRA)" <ji...@apache.org> on 2016/07/28 11:06:20 UTC

[jira] [Commented] (LANG-1040) Javadoc for NumberUtils.isNumber() are not clear enough

    [ https://issues.apache.org/jira/browse/LANG-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15397398#comment-15397398 ] 

Rob Tompkins commented on LANG-1040:
------------------------------------

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)