I'm trying to read the stdin in my Java program. I'm expecting a series of numbers followed by newlines, like:
6
9
1
When providing the input through the eclipse built-in console, everything goes well. But when using the Windows command line, the program prints:
Received '6'.
Received 'null'.
Invalid input. Terminating. (This line is written by another function that does an Integer.parseint()).
My code is:
static String readLineFromStdIn(){
try{
java.io.BufferedReader stdin = new java.io.BufferedReader(new java.io.InputStreamReader(System.in));
String input = new String();
input = stdin.readLine();
System.out.println("Received '" + input + "'");
return(input);
}catch (java.io.IOException e) {
System.out.println(e);
}
return "This should not have happened";
}
Any clues?
Not really a new answer to this question, but I wanted to clear up confusion in the comments about why the original code behaved as it did (I can't comment because I'm new to ST and haven't garnered reputation points).
The null result has nothing to do with garbage collection. The following program suffers exactly the same fate even though both readers still live, accessible objects:
It all comes down to what "Buffered" means in
BufferedReader
. It's aReader
that includes internal buffering. The internal buffering usually significantly improves the efficiency of operations on the underlying stream, e.g. by attempting to read a full buffer's worth each time, rather than nickle-and-diming the stream to death getting a few bytes here and a few there.So what happens when you create the first
BufferedReader
on stdin and read a line from it? ThatBufferedReader
reads a buffer-full from the stream, detects the end of line, returns the first line, and hangs on to the rest of the buffer to fill its next request. That leaves the underlying stream positioned beyond the end of that first line. And if your input is small, it could easily be positioned at EOF.So now you come along and create a second BufferedReader atop the same stream - which is at EOF - and attempt to get a line. The second BufferedReader attempts to read from the underlying stream and detects EOF, so
readLine
returnsnull
.That you get a
null
indicates that the relevantReader
objects reached an EOF (end of file), or in other words that they can't get any more standard input. Now the obvious issues with your code are:readLineFromStdIn()
will create a newBufferedReader
.BufferedReader
will be “competing” with each other for the same, shared input fromSystem.in
BufferedReader
objects are ever properly closed, so your program leaks I/O resources with each call toreadLineFromStdIn()
.The solution is to use a single shared
BufferedReader
object for each invocation ofreadLineFromStdIn()
.