It all depends on the underlying stream. Ultimately, either one of these has to call InputStream.read() on some InputStream. If that read() call blocks, then the methods you've shown will block as a result. In most cases, as long as an InputStream isn't in an "end-of-file" state, read() will block and wait for input.
[John Meyers]: Although the function is abstract, it looks like one has to assume that the underlying implementation will block until input data is available.
I would say it's more than an assumption - it's the way all InputStreams and Readers are required to work. If these methods didn't block, what would they return? The read() method returns -1 to indicate end of file (or end of stream as the case may be), and readLine() returns a null for the same thing. You can't use -1 or null to indicate that the stream is merely waiting for more input, because that hasn't been documented in any way, and there's no reason for users of the stream to interpret a -1 or null as anything other than an end of the stream.
It would be theoretically possible to write a subclass of InputStream or Reader that did not obey its own API, and instead returned -2 or an empty String - but such a class would be very difficult for anyone else to use. Anyone trying to use it as a normal InputStream or Reader would get very confusing results, and would probably end up feeling somewhat homicidal towards the original author of the offending class. Not recommended.
If you want to be able to use a Socket in non-blocking mode, stay away from the InputStream and use getChannel() instead. [ February 18, 2007: Message edited by: Jim Yingst ]