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