[
https://issues.apache.org/jira/browse/LANG-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Sawle updated LANG-992:
-----------------------------
Attachment: LANG-992 Refactor.patch
This is a possible large refactor of the isNumber functionality extracting each
of the different datatypes into their own methods. Whilst this will not be as
efficient as the original method, it is more maintainable and would allow the
possibility of making each of them public separately.
I understand that this may be a step to far, but would be interested in hearing
people's views. This does not however, cover Sebb's point about 01.23 as I do
not believe that createNumber should be allowing it.
> 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: 3.3.2
>
> Attachments: LANG-992 Refactor.patch, LANG-992-v2.patch
>
>
> After upgrading 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 means neither hex nor octal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
