commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LANG-1252) NumberUtils.isNumber and NumberUtils.createNumber resolve inconsistently
Date Sun, 11 Sep 2016 16:34:20 GMT

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

ASF GitHub Bot commented on LANG-1252:
--------------------------------------

Github user britter commented on a diff in the pull request:

    https://github.com/apache/commons-lang/pull/186#discussion_r78298119
  
    --- Diff: src/main/java/org/apache/commons/lang3/math/NumberUtils.java ---
    @@ -1360,11 +1361,44 @@ public static boolean isDigits(final String str) {
          * <p><code>null</code> and empty/blank {@code String} will return
          * <code>false</code>.</p>
          *
    +     * <p>Note, {@link #createNumber(String)} should return a number for every
    +     * input resuling in <code>true</code>.</p>
    +     *
          * @param str  the <code>String</code> to check
          * @return <code>true</code> if the string is a correctly formatted number
    -     * @since 3.3 the code supports hex {@code 0Xhhh} and octal {@code 0ddd} validation
    +     * @since 3.3 the code supports hex {@code 0Xhhh} an
    +     *        octal {@code 0ddd} validation
    +     * @deprecated This feature will be removed in Lang 4.0,
    +     *             use {@link NumberUtils#isCreatable(String)} instead
          */
    +    @Deprecated
         public static boolean isNumber(final String str) {
    +        return isCreatable(str);
    +    }
    +
    +    /**
    +     * <p>Checks whether the String a valid Java number.</p>
    +     *
    +     * <p>Valid numbers include hexadecimal marked with the <code>0x</code>
or
    +     * <code>0X</code> qualifier, octal numbers, scientific notation and
    +     * numbers marked with a type qualifier (e.g. 123L).</p>
    +     *
    +     * <p>Non-hexadecimal strings beginning with a leading zero are
    +     * treated as octal values. Thus the string <code>09</code> will return
    +     * <code>false</code>, since <code>9</code> is not a valid
octal value.
    +     * However, numbers beginning with {@code 0.} are treated as decimal.</p>
    +     *
    +     * <p><code>null</code> and empty/blank {@code String} will return
    +     * <code>false</code>.</p>
    +     *
    +     * <p>Note, {@link #createNumber(String)} should return a number for every
    +     * input resuling in <code>true</code>.</p>
    +     *
    +     * @param str  the <code>String</code> to check
    +     * @return <code>true</code> if the string is a correctly formatted number
    +     * @since 3.3 the code supports hex {@code 0Xhhh} and octal {@code 0ddd} validation
    --- End diff --
    
    should be changed to simply `@since 3.5`


> NumberUtils.isNumber and NumberUtils.createNumber resolve inconsistently
> ------------------------------------------------------------------------
>
>                 Key: LANG-1252
>                 URL: https://issues.apache.org/jira/browse/LANG-1252
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.math.*
>    Affects Versions: 3.4
>            Reporter: Rob Tompkins
>            Assignee: Rob Tompkins
>             Fix For: Discussion
>
>
> In considering the issues LANG-1060, LANG-1040, LANG-1038, and LANG-992, it seems that
there are times when {{NumberUtils.isNumber}} resolves to {{false}} while {{NumberUtils.createNumber}},
given the same input, does not throw an exception, returning a valid {{java.lang.Number}}.
This inconsistency should be resolved either by making {{isNumber}} more lenient or {{createNumber}}
more stringent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message