JDK-6437114 : Change in java.util.Scanner.findInLine(".") behavior
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2006-06-10
  • Updated: 2010-04-02
  • Resolved: 2006-06-15
Related Reports
Relates :  
Description
Reference this forum posting:

http://forums.java.net/jive/thread.jspa?threadID=16058&tstart=0


If I compile and execute the following program FROM THE WINDOWS COMMAND LINE, I get different behavior under Java 6 than I did under Java 5. (With Java 6, I get a NullPointerException; with Java 5, I didn't.)

import java.util.Scanner;

public class TestScan {

    public static void main(String args[]) {
	Scanner keyboard = new Scanner(System.in);

	System.out.print("Number: ");
	int i = keyboard.nextInt();
	System.out.print("char: ");
	char c = keyboard.findInLine(".").charAt(0);
    }
}
Teasing apart the submitted test case shows that java.util.Scanner.findInLine(".") is returning null where it returned a String in earlier releases:

import java.util.Scanner;

public class TestScan {

    public static void main(String args[]) {
	Scanner keyboard = new Scanner(System.in);

	System.out.print("Number: ");
	int i = keyboard.nextInt();
	System.out.print("char: ");
	String s = keyboard.findInLine(".");
	if (s != null) {
	    char c = s.charAt(0);
	    System.out.println("c is: " + c);
	} else {
	    System.out.println("s is null.");
	}
    }
}

% java -showversion TestScan
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b45)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b45, mixed mode)

Number: 8
char: s is null.

Comments
EVALUATION The "behavior change" is the expected result of bug fix for 6269946. After the invoke of "keyboard.nextInt()", the line terminator/newline character(s)is still in the input stream buffer, so the correct result of keyboard.findInLine("."), as the spec says, should return "null", since there is NOTHING to match pattern "." between current position and the next line terminator. The behavior of 5.0 and earlier are incorrect, we fixed it in 6.0.
15-06-2006