JDK-4096613 : Float and Double.valueOf(String) don't throw NumberFormatException.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.1.4,1.2.0,1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_2.5,windows_2000
  • CPU: x86,sparc
  • Submitted: 1997-12-03
  • Updated: 2006-02-07
  • Resolved: 2006-02-07
Related Reports
Duplicate :  
Description
Name: aaC67449			Date: 12/03/97



Float.valueOf(String),
Double.valueOf(String),
Float(String) and
Double(String)
accept integer literals (i.e. literals without decimal point).
According to the JLS (20.9.17, 20.10.16), the NumberFormatException
shold be thrown.

JLS 20.9.17:
"
20.9.17 public static Float valueOf(String s)
throws NullPointerException, NumberFormatException 

The string s is interpreted as the representation of a floating-point value and a Float object representing that value is created and returned. 

If s is null, then a NullPointerException is thrown.

Leading and trailing whitespace (?20.5.19) characters in s are ignored. The rest of s should constitute a FloatValue as described by the lexical syntax rules:

    FloatValue:

            [Sign] Digits . [Digits] [ExponentPart]

            [Sign] . Digits [ExponentPart]

where Sign, Digits, and ExponentPart are as defined in ?3.10.2. If it does not have the form of a FloatValue, then a NumberFormatException is thrown. Otherwise, it is regarded as representing an exact decimal value in the usual "computerized scientific notation"; this exact decimal value is then conceptually converted to an "infinitely precise" binary value that is then rounded to type float by the usual round-to-nearest rule of IEEE 754 floating-point arithmetic. Finally, a new object of class Float is created to represent this float value. 

Note that neither F nor f is permitted to appear in s as a type indicator, as would be permitted in Java source code (?3.10.1).

"
-------------Example ---------------

public class Test {

public static void main( String argv[] ) {
 try {
     Float.valueOf("1");
     System.out.println("FAILED. No NumberFormatException.");
 }catch(NumberFormatException e) {
    System.out.println("PASSED");
 }

 try {
     Float.valueOf("1234");
     System.out.println("FAILED. No NumberFormatException.");
 }catch(NumberFormatException e) {
    System.out.println("PASSED");
}
 
}

---------Output from the test---------------------
FAILED. No NumberFormatException.
FAILED. No NumberFormatException.
--------------------------------------------------



======================================================================

Name: rmT116609			Date: 09/19/2002


DESCRIPTION OF THE PROBLEM :
Long.valueOf("   12   ");   throws NumberFormatException, Same with Integer

 

Double.valueOf(" 12    "); does a trim and doesn't throw anything.  Same as Float.


EXPECTED VERSUS ACTUAL BEHAVIOR :
Consistency, either trim the string in the valueOf method all-the-time or don't trim.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class NumberTest
{

   public static void main(String[] args)
   {

      String numberString = "   20  ";
      try
      {
         System.out.println(Long.valueOf(numberString));
      }
      catch (NumberFormatException npe)
      {
         System.out.println("caught number format expection");
      }
      try
      {
          System.out.println(Double.valueOf(numberString));
      }
      catch (NumberFormatException npe)
      {
         System.out.println("caught number format expection");
      }

   }
}
---------- END SOURCE ----------
(Review ID: 164754)
======================================================================

Comments
PUBLIC COMMENTS java.lang.Double and java.lang.Float valueOf() The JLS disallows trailing d,D,f or F as arguments to the conversion routines Double.valueOf() and Float.valueOf(). However, these forms have been allowed by some implementations for some time. Modifying the specification makes the rules more uniform and preserves compatibility with all existing Java programs. The lexical syntax rule and the surrounding text in both JLS 20.9.17 and 20.10.16 should read: The rest of s should constitute a FloatValue as described by the lexical rule: FloatValue: Sign_opt FloatingPointLiteral where Sign and FloatingPointLiteral are as defined in section 3.10.2. The final paragraph in both sections will be deleted as well.
10-06-2004

EVALUATION This is a duplicate of an old bug. More importantly, the spec has been changed to address this a long time ago. See http://java.sun.com/docs/books/jls/clarify.html gilad.bracha@eng 1998-04-03 ================================================================ This bug is not a duplicate of the one complaining about trailing F and D letters. This one is different. The new version of the specification found at http://java.sun.com/docs/books/jls/clarify.html still does not permit an INTEGER literal (i.e. one containing digits only) to be parsed with these methods. That is "1" and "1234" are still illegal arguments according to the spec. So the test example from the bugreport correctly expects NumberFormatException. This should be investigated further. vvs@russia 1998-04-10
10-04-1998