http://svn.apache.org/repos/asf/tomcat/taglibs/standard/trunk/impl/src/main/java/org/apache/taglibs/standard/tag/common/fmt/FormatNumberSupport.java ==== 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), nfe); } } ==== End of cut ========== What about string value "0e-8"? It is a normal zero value but exception throws.
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.
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').
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...
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 ======= FloatValue: 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. FloatingPointLiteral: Digits . Digitsopt ExponentPartopt FloatTypeSuffixopt . Digits ExponentPartopt FloatTypeSuffixopt Digits ExponentPart FloatTypeSuffixopt Digits ExponentPartopt FloatTypeSuffix ExponentPart: 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?
Resolving as WONTFIX as the spec defines what we must do here.