Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 452235

Summary: java.util.Scanner.nextFloat() not working
Product: [Fedora] Fedora Reporter: Andrea Santilli <andreasantilli>
Component: java-1.6.0-openjdkAssignee: Thomas Fitzsimmons <fitzsim>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 9CC: langel, lkundrak, mjw
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-20 16:07:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
the test program sources
none
text file i used to test the method none

Description Andrea Santilli 2008-06-20 13:40:31 UTC
Description of problem:
java.util.Scanner.nextFloat() raises java.util.InputMismatchException while
reading a floating point number.
Please notice that I could workaround this by using
Float.parseFloat(myScanner.next())
I'm attaching a simple test program and a test text file: try to run it with
both JDK and OpenJDK and you'll see the difference.

Version-Release number of selected component (if applicable):
1.6.0.0-0.15.b09.fc9

How reproducible:
Always

Steps to Reproduce:
1. Just create a new Scanner object with a string containing only a floating
point number
2. it will compile fine as exspected
3. but it will raise the InputMismatchException

Additional info:
I still didn't test the other methods of java.util.Scanner so I can't say
whether they will work or not.

Comment 1 Andrea Santilli 2008-06-20 13:40:31 UTC
Created attachment 309918 [details]
the test program sources

Comment 2 Andrea Santilli 2008-06-20 13:41:35 UTC
Created attachment 309919 [details]
text file i used to test the method

Comment 3 Lillian Angel 2008-06-20 16:07:38 UTC
java-1.6.0-openjdk-1.6.0.0-0.15.b09.fc9.i386

$ java Test test.txt 
0.123

$ /opt/jdk1.6.0_03/bin/java Test testtt 
0.123

$ java -version
java version "1.6.0"
OpenJDK  Runtime Environment (build 1.6.0-b09)
OpenJDK Server VM (build 1.6.0-b09, mixed mode)



Comment 4 Lillian Angel 2008-06-20 16:08:18 UTC
testtt and test.txt are identical to the text file you attached

Comment 5 Lubomir Rintel 2008-06-20 20:29:37 UTC
Lillian: I am wondering whether you tried this on PowerPC?

gbenson once pointed me to an issue very similar to this, that was an
explanation for a problem I had on ppc. It was occuring with an early version of
GNU Classpath IIRC.

Comment 6 Andrea Santilli 2008-06-21 10:11:26 UTC
I tried to reinstall all the packages but sorry, it still doesnt work for me.
this is the output i get by running the test program:

$ java Test test.txt
java.util.InputMismatchException
        at java.util.Scanner.throwFor(Scanner.java:857)
        at java.util.Scanner.next(Scanner.java:1478)
        at java.util.Scanner.nextFloat(Scanner.java:2336)
        at Test.main(Test.java:28)
Scanner.nextFloat() is screwed... let's try something else.
0.123

That's really weird because it looks like nextFloat() calls next() anyway.
Oh anyway I'm not on a PowerPC, just an Aspire 5630



Comment 7 Lillian Angel 2008-06-23 14:34:13 UTC
I tested this on an i386, I will test it on x86_64 as well.

Comment 8 Lillian Angel 2008-06-24 18:34:19 UTC
works on x86_64

$  java Test attachment.cgi
0.123
$ java -version
java version "1.6.0"
OpenJDK  Runtime Environment (build 1.6.0-b09)
OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)