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

Bruno P. Kinoshita commented on LANG-1040:
------------------------------------------

> Or we define exactly what we accept by specifying a grammar in the Javadocs.

I think that's probably the best scenario for users.

I tried using the following code found in [this StackOverflow 
answer|http://stackoverflow.com/questions/1102891/how-to-check-if-a-string-is-a-numeric-type-in-java]
 to replace isNumber, and then executed the NumberUtilsTest#testIsNumber test 
method:

{noformat}
        try {
            Double.parseDouble(str);
        } catch (NumberFormatException e) {
            return false;
        }
        return true;
{noformat}

And the test failed with:

{noformat}
java.lang.AssertionError: Expecting true for isNumber/createNumber using 
"-0xABC123" but got false and true
{noformat}

Using the Regex version:

{noformat}
        return str.matches("-?\\d+(\\.\\d+)?");
{noformat}

Results in:

{noformat}
java.lang.AssertionError: Expecting true for isNumber/createNumber using 
".12345" but got false and true
{noformat}

And the final example:

{noformat}
        NumberFormat formatter = NumberFormat.getInstance();
        ParsePosition pos = new ParsePosition(0);
        formatter.parse(str, pos);
        return str.length() == pos.getIndex();
{noformat}

Gives:

{noformat}
java.lang.AssertionError: Expecting true for isNumber/createNumber using 
"1234E+5" but got false and true
{noformat}

Maybe we can fix this issue by enhancing the docs with a grammar and some 
examples of what the method can and cannot handle?

> 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)

Reply via email to