It does advance through the input stream. It just doesn't advance past the next input, from the Scanner
and Scanner
user's point of view. So arguably this piece of documentation is badly worded.
This can be easily tested by putting just a single token in a stream, and then calling hasNext
for that token. In that case, you'll find that the stream is exhausted after calling hasNext
.
In other words, the Scanner
buffers the peeked characters internally, including any delimiter characters. Subsequent calls will then start out from the buffered characters. Scanner
doesn't rely on any buffering provided by the underlying stream.
This text is at least present until Java 12.
Example code:
Reader stringReader = new StringReader("Single line");
Scanner firstScanner = new Scanner(stringReader);
// prints out true because there is a first line
System.out.println(firstScanner.hasNextLine());
Scanner secondScanner = new Scanner(stringReader);
// prints out false because the scanner has advanced the reader
// ... through the character stream generated from the string
System.out.println(secondScanner.hasNextLine());
// prints out true because the first scanner is buffering the input
System.out.println(firstScanner.hasNextLine());
It also contains other documentation issues with hasNext
, for instance in the documentation of the Scanner
class itself it reads:
The next()
and hasNext()
methods and their companion methods (such as nextInt()
and hasNextInt()
) first skip any input that matches the delimiter pattern, and then attempt to return the next token.
obviously the last part is not true for hasNext()
. This looks like hasNext
has been shoe-horned into an existing sentence.