[
https://issues.apache.org/jira/browse/LANG-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13949713#comment-13949713
]
Bernd Eckenfels commented on LANG-992:
--------------------------------------
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)". Because the Java
syntax and literal format is not really something which you use anywhere
outside the compiler/source tools.
However, I would be fine with both definitions, as long as they are added to
the javadoc comment.
BTW1: I have some applications where the NFE is a major slow down as I use the
parse function to validate. So I do see a big reason for having a boolean
validate function.
BTW2: I think hex/ocatal prefixes and decimal digits are never seen in the same
function, so I think having a "isInteger()" which knows about octal/hex and
having a isNumber() which fails on hex and ignores trailing 0 would be a more
logical thing.
> NumberUtils#isNumber() returns false for "0.0", "0.4790", et al
> ---------------------------------------------------------------
>
> Key: LANG-992
> URL: https://issues.apache.org/jira/browse/LANG-992
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
> Affects Versions: 3.3.1
> Environment: Java 8, Windows 7
> Reporter: Adam Rauch
> Fix For: Review Patch
>
> Attachments: LANG-992-v2.patch
>
>
> After upgraded from 3.1 to 3.3.1 it seems that {{isNumber(String str)}}
> returns false for decimal numbers with leading zeros. In other words:
> {code:java}
> boolean ret = NumberUtils.isNumber("0.4790");
> {code}
> On 3.1, {{ret}} was true. In 3.3.1, {{ret}} is false.
> Guessing that LANG-972 is related... comment in the code states:
> {code:java}
> // leading 0, but not hex, must be octal
> {code}
> This is clearly a case where leading 0 does not mean hex.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
