BufferedInputStream is a wrapper class that wraps an InputStream. When you call close() on a BufferedInputStream object, you are actually closing the InputStream that it wraps, so, in this case, you are closing the standard input stream (System.in) which is never a good idea. When you call the method a second time, you try and wrap the standard input stream, but as it is closed you get an error when you try to read from it.
Unless you are planning on typing some very long lines, I doubt there is much advantage to buffering the standard input, so you should just use System.in in your method and not close it.
And, by the way, this is nothing to do with the method being static. You would have had the same problem in a non-static method.
[ August 22, 2008: Message edited by: Joanne Neal ] [ August 22, 2008: Message edited by: Joanne Neal ]
Joined: Aug 20, 2008
Ok, I understand the part about static methods.
For the input stream, I read about the wrappers in my text book. So the class System has a class variable 'in' that is an InputStream object. The book only mentions the possibility to create a new buffered input stream, but you wrote that that is not necessary. I can not make an instance of InputStream (error message) so you should I use the InputStream object without something like a wrapper?
Joined: Aug 05, 2005
I think you need to distinguish between InputStreams in general and System.in which is a specific instance of an InputStream.
System.in is an InputStream object that is created automatically when you start a Java program and it is connected to the OS's standard input stream. As this is usually the system console, it means you can use it to read what a user types and you don't have to worry about creating it.
A BufferedInputStream is what is known as a wrapper class. It adds extra functionality to the class (in this case an InputStream) that it 'wraps'. A BufferedInputStream adds the ability to buffer the input and to support the mark and reset methods. In the case of System.in I don't believe it is necessary to wrap it in a BufferedInputStream, but as I don't write many programs that make use of System.in other people may have a different view. Did your book specifically show an example of creating a BufferedInputStream around System.in or was it just a general case of wrapping an InputStream in a BufferedInputStream.
If you do wrap System.in in a BufferedInputStream, then you shouldn't close it until you have finished with it as you are not able to reopen it.
You're right about not being able to create an InputStream object. This is because it is an abstract class, but there are plenty of concrete classes that extend it. See the javadoc for a list.
There are plenty of good reasons for wrapping certain InputStream objects in a BufferredInputStream. My comments about not using a BufferredInputStream were specifically about wrapping System.in. As i said, other people may have other opinions.
I've rambled on for a bit there. I hope it makes sense, but feel free to ask more questions if you're still unsure. [ August 22, 2008: Message edited by: Joanne Neal ]
I read the tutorial on I/O from the command line and the console. The example that is given there, using the console, seems to add another level of difficulty for me.
However, I think I understand the mechanism of the (Buffered)InputStream now.
I edited the example by removing the line "buff.close();" Now I can read multiple input lines.
I followed your suggestion not to use BufferedInputStream too and made an second example. I left out all the lines containing BufferedInputStream and replace "in = buff.read();" with "in = System.in.read();"
Thank you very much for your help. You gave me valuable new insights!
If you are using Console you must be on Java6. It's worth going back to Java5 and finding that most useful class java.util.Scanner, which can have System.in passed to its constructor and will read lines, ints, BigDecimals from anywhere you care to send it.
And it still works beautifully in Java6.
Joined: Aug 20, 2008
Yes, I'm using Java6 and a textbook on that version as well. They don't mention the Scanner class which is a pity because this is exactly the thing I would Java expect to have. Thanks for pointing this out and I just order Head Start Java which seems a better book (I read on this forum) and covers Java5.