Bug 51234

Summary: NumberFormatException in fmt:formatNumber tag
Product: Taglibs Reporter: Alexander Kupcov <a.kupcov>
Component: Standard TaglibAssignee: Tomcat Developers Mailing List <dev>
Severity: normal    
Priority: P2    
Version: 1.1.0   
Target Milestone: ---   
Hardware: PC   
OS: Linux   

Description Alexander Kupcov 2011-05-20 09:37:47 UTC

==== Cut ====

        if (input instanceof String) {
            try {
                if (((String) input).indexOf('.') != -1) {
                    input = Double.valueOf((String) input);
                } else {
                    input = Long.valueOf((String) input);
            } catch (NumberFormatException nfe) {
                throw new JspException(
                        Resources.getMessage("FORMAT_NUMBER_PARSE_ERROR", input),

==== End of cut ==========

What about string value "0e-8"? It is a normal zero value but exception throws.
Comment 1 Christopher Schultz 2011-05-20 15:24:57 UTC
I don't see any documentation that mandates what formats are acceptable to the "value" attribute of this tag.

One could argue that it doesn't accept European-style decimals numbers like "1,05" for 1 + point-oh-five, etc. (that's what <fmt:parseNumber> is for).

But it's true that "0e-8" is a valid String-value for a double, so the code could afford to be modified at least slightly.
Comment 2 Alexander Kupcov 2011-05-20 19:45:51 UTC
I'm getting data from a database query. One of the values ​​- 0 in the form of "0E-8" and this value can not be shown in the output JSP because an exception is thrown. I do not use European-style decimals numbers. I think one of the solutions - in this example, besides the point look for the presence of a character 'e' (and 'E').
Comment 3 Kris Schneider 2011-05-20 20:09:41 UTC
From the JSTL 1.2 spec:

If the numeric value is given as a string literal, it is first parsed into a java.lang.Number. If the string does not contain any decimal point, it is parsed using java.lang.Long.valueOf(), or java.lang.Double.valueOf() otherwise.

So the code appears to at least match the spec, for what it's worth. As a workaround, perhaps you can make use of the pattern attribute...
Comment 4 Alexander Kupcov 2011-05-21 09:50:32 UTC
Thanks for the link to the specification JSTL, but...

From javadoc (
http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Double.html#valueOf%28java.lang.String%29) :
============= cut =======
        Signopt NaN 
        Signopt Infinity 
        Signopt FloatingPointLiteral 

where Sign and FloatingPointLiteral are as defined in §3.10.2 of the Java Language Specification.
============= end of cut =======

well, look at the The Java Language Specification:

============= cut =======
3.10.2 Floating-Point Literals
See §4.2.3 for a general discussion of the floating-point types and values.

A floating-point literal has the following parts: a whole-number part, a decimal point (represented by an ASCII period character), a fractional part, an exponent, and a type suffix. The exponent, if present, is indicated by the ASCII letter e or E followed by an optionally signed integer.

At least one digit, in either the whole number or the fraction part, and either a decimal point, an exponent, or a float type suffix are required. All other parts are optional.

A floating-point literal is of type float if it is suffixed with an ASCII letter F or f; otherwise its type is double and it can optionally be suffixed with an ASCII letter D or d.

	Digits . Digitsopt ExponentPartopt FloatTypeSuffixopt
	. Digits ExponentPartopt FloatTypeSuffixopt
	Digits ExponentPart FloatTypeSuffixopt
	Digits ExponentPartopt FloatTypeSuffix

	ExponentIndicator SignedInteger

ExponentIndicator: one of
	e E

============= end of cut =======

I think that's enough. As a result, I think, JSTL ignores (or the developers have missed this point) ExponentIndicator in floating point numbers.

What do you think maybe it's worth to fix a mistake?
Comment 5 Jeremy Boynes 2012-02-25 19:46:41 UTC
Resolving as WONTFIX as the spec defines what we must do here.