9

I am trying to understand how these three methods work. Here's how I understood them:

  • nextLine() reads the remainder of the current line even if it is empty.
  • nextInt() reads an integer but does not read the escape sequence "\n".
  • next() reads the current line but does not read the "\n".

Suppose I have the following code: 

import java.util.Scanner;

public class Welcome2
{
    public static void main(String[] args)
    {
        Scanner keyboard = new Scanner(System.in);
        System.out.println("Next enter two words:");

        int n; 
        String s1, s2; 

        n = keyboard.nextInt(); 
        s1 = keyboard.next(); 
        s2 =  keyboard.nextLine(); 
        System.out.println(" n is " + n + " s1 is " + s1 + " s2 is " + s2); 
    }
}

If my input is : 

2 

Hi 

Hello

Then I get the following output on screen: 

n is 2 
s1 is hi 
s2 is

Why would s1 have a value of "HI"?

Does this mean that the method next() reads the next line even though the escape character for the first line has not been read by nextInt()?

bangbang
  • 843
  • 1
  • 18
  • 39
  • 5
    `next()` doesn't read the current line - it reads the next *token*. How did you enter that "2 Hello Hi"? If you'd hit return twice, the program would have ended before you got to enter the "Hi"... – Jon Skeet Sep 26 '15 at 15:32
  • I entered the first value, the hit enter, then second, hit enter, third. I just hit enter once between my inputs. – bangbang Sep 26 '15 at 15:34
  • 1
    Are you running this from the command line? Are you sure you're running the *exact* code that you posted? Because when I run that and try the exact sequence you've said, it prints " n is 2 s1 is Hello s2 is" and doesn't give me time to enter "Hi" at all. Note that your sample output is on three lines as well, which your sample code wouldn't give. I suspect you haven't posted the actual code you're running. (If you modify the code, please take the time to format it, as I have for your current code. It's *much* harder to read code that hasn't been indented appropriately.) – Jon Skeet Sep 26 '15 at 15:36
  • I do apologize for the bad format. I have fixed the suggested errors. The second input should be hi. – bangbang Sep 26 '15 at 15:38
  • 1
    As Jon mentioned `next` tries to read token, not line. What you need to know is that it will not consume line separator after that token, but it will be able to consume and skip any line separators which are placed before it. For instance lets say that `|` is Scanners cursor and it is placed in text `2|\r\nfoo\r\nbar`. If you invoke `next()` it will read `\r` `\n` and finally it will find `foo`. It will also read next character `\r` to check where this tokken ends, but it will not *consume* it (causing `nextLine` to consume it and return empty string). – Pshemo Sep 26 '15 at 15:47

3 Answers3

5

nextLine() reads the remainder of the current line even if it is empty.

Correct.

nextInt() reads an integer but does not read the escape sequence "\n".

Correct1.

next() reads the current line but does not read the "\n".

Incorrect. In fact, the next() method reads the next complete token. That may or may not be the rest of the current line. And it may, or may not consume an end-of line, depending on where the end-of-line is. The precise behavior is described by the javadoc, and you probably need to read it carefully for yourself in order that you can fully understand the nuances.

So, in your example:

  1. The nextInt() call consumes the 2 character and leaves the position at the NL.

  2. The next() call skips the NL, consumes H and i, and leaves the cursor at the second NL.

  3. The nextLine() call consumes the rest of the 2nd line; i.e. the NL.

1 ... except that your terminology is wrong. When the data is being read, it is not an escape sequence. It is an end-of-line sequence that could consist of a CR, a NL or a CR NL depending on the platform. The escape sequences you are talking about are in Java source code, in string and character literals. They may >>represent<< a CR or NL or ... other characters.

Stephen C
  • 632,615
  • 86
  • 730
  • 1,096
3

If your input is 2 hello hi

nextInt() - just read the next token as a int (Here - it is 2) otherwise it give error

next() - Just read the next token, (here - it is hello)

nextline() - It read a line until it gets newline (here - after read previous 2 hello input by nextInt, next; nextline read hi only because after that it finds a newline )

if input is

2 

Hi 

Hello

nextInt, next is same for above discussion .

In nextline(), it finds newline after completing the input Hi read by next(). So, nextline() stops to read input for getting the newline character.

Animesh Kumar Paul
  • 2,033
  • 3
  • 22
  • 36
  • this is actually inaccurate. if the input is "2 hello hi", then nextInt() will read token "2" and next() will read token "hello" but nextLine() will be " hi" with a space infront of hi because next() will place the cursor right after the consumed token – csguy May 13 '19 at 02:14
-1

Does this mean that the method next() reads the next line even though the escape character for the first line has not been read by nextInt()?

NO.

  1. next() cannot read next line, it only reads something before space.

  2. When keyboard.nextLine() executes, it consumes the "end of line" still in the buffer from the first input.

  3. when you enter a number then press Enter, keyboard.nextInt() consumes only the number, not the "end of line".

Using next() will only return what comes before a space. nextLine() automatically moves the scanner down after returning the current line.

JumpMan
  • 2,016
  • 3
  • 22
  • 37
  • Actually `next()` **can** consume a newline, because newlines are included in the default "white space" delimiter pattern. The Javadoc says: *"The default whitespace delimiter used by a scanner is as recognized by Character.isWhitespace."* And in fact, in the OP's example, it **does** consume a newline; i.e. the one after the `2` character. Granted, it doesn't include the delimiter characters in the string that it returns ... but that is a separate issue. – Stephen C Sep 27 '15 at 00:32