commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Barnhill <>
Subject Re: [LANG] LANG-1252 - NumberUtils.isNumber and NumberUtils.createNumber resolve inconsistently
Date Tue, 06 Sep 2016 13:07:26 GMT
> Implementation thoughts:
> (1) Switch implementation “isNumber” -> “isParsable”
> (2) Deprecate “isNumber” and have it call “isParsable"
> (3) Rename “createNumber” to “parseNumber” (with Deprecation)
> (4) Fix subtle differences between “parseNumber” and newly implemented
> “isParsable"
> (5) Write “isJavaNumberLiteral” from beginning.

I took a look at the code. As far as design goes I think they are all good
improvements. I did notice this in the doc:

<p>Parsable numbers include those Strings understood by {@link
     * {@link Long#parseLong(String)}, {@link Float#parseFloat(String)} or
     * {@link Double#parseDouble(String)}. This method can be used instead
of catching {@link java.text.ParseException}
     * when calling one of those methods.</p>
<p>Hexadecimal and scientific notations are <strong>not</strong> considered

So this makes me wonder if a method called isParsable should in fact be
able to parse these numbers? Is this doc canonical somehow, or just how
previous contributors chose to think about the issue? In which case the doc
could be restated, saying for example "Hexadecimal and scientific notations
are <strong>not</strong> considered Number Literals."

Regarding point 5, this page

uses the term "Numeric Literal", perhaps that is better phrasing than
"Number Literal"?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message