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

Juan Pablo Santos Rodríguez commented on LANG-997:
--------------------------------------------------

Hi Bernd,

saw the octal issue, but my concern was that NumberUtils on 3.2.1 was returning 
true for, i.e., "018" and now is returning false, considering that "018" is a 
valid number. I expected for this method the same behaviour you described at 
[LANG-992|https://issues.apache.org/jira/browse/LANG-992?focusedCommentId=13949713&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13949713]:

{quote}
Actually my expectation for using that method would be that "isNumber returns 
true if I can use it without a NumberFormatException with 
Integer.parseInt(String) or Double.parseDouble(String)"
{quote}

I expected that "018" was recognized as a valid number, because as it can be 
used as new Integer( "018" ), without any NFExceptions, it made sense to me 
that it was recognized as a valid Java number, hence isNumber( "018" ) should 
return true. Then went into LANG-971 issue link and and saw that this is not 
the method intention. I found it a bit surprising.

We've been using this method to check if some fixed-width values were "numbers" 
or not (as in behaviour described on the quote above), and when upgrading 
suddenly a lot of tests began to fail because of this change. Seems we'll have 
to seek for a workaround if we want to upgrade this library. It'd be fine for 
me if at least the javadocs would give a more precise description regarding the 
scope of the method or, maybe some examples of the method outcomes on the 
method's javadoc (as it's done on StringUtils, f.ex).


> NumberUtil#isNumber() returns false for "012345678" but not for "12345678"
> --------------------------------------------------------------------------
>
>                 Key: LANG-997
>                 URL: https://issues.apache.org/jira/browse/LANG-997
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.math.*
>    Affects Versions: 3.3.2
>         Environment: Java 6
>            Reporter: Juan Pablo Santos Rodríguez
>             Fix For: Review Patch, Discussion, 3.4
>
>
> With commons-lang 3.2.1:
> {code}
> boolean ret = NumberUtils.isNumber( "012345678901234567" );
> {code} 
> returns {{true}}, but for 3.3.2, returns {{false}}.
> The change seems to be introduced in LANG-972 / LANG-992, as it seems to 
> consider now that, if the parameter string has a leading 0, and it's not hex, 
> then it must be forcibly octal.
> As previous 3.x versions accept 0ddd as valid decimal numbers, the suggested 
> change on NumberUtils#isNumber, is to replace lines 
> [1367-1376|http://commons.apache.org/proper/commons-lang/xref/org/apache/commons/lang3/math/NumberUtils.html#L1367]
>  with:
> {code}
>            } else if (Character.isDigit(chars[start + 1])) {
>                // leading 0, but not hex, must be octal or decimal
>                int i = start + 1;
>                for (; i < chars.length; i++) {
>                    if (chars[i] < '0' || chars[i] > '9') { // was: if 
> (chars[i] < '0' || chars[i] > '7') {
>                        return false;
>                    }
>                }
>                return true; 
>            }
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to