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 - java.util.Scanner.nextFloat() not working
Summary: java.util.Scanner.nextFloat() not working
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk
Version: 9
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Thomas Fitzsimmons
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-20 13:40 UTC by Andrea Santilli
Modified: 2008-06-24 18:34 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-06-20 16:07:38 UTC


Attachments (Terms of Use)
the test program sources (deleted)
2008-06-20 13:40 UTC, Andrea Santilli
no flags Details
text file i used to test the method (deleted)
2008-06-20 13:41 UTC, Andrea Santilli
no flags Details

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)


Note You need to log in before you can comment on or make changes to this bug.