aspose file tools*
The moose likes I/O and Streams and the fly likes Will these methods wait for input? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » I/O and Streams
Bookmark "Will these methods wait for input?" Watch "Will these methods wait for input?" New topic
Author

Will these methods wait for input?

Jesus Angeles
Ranch Hand

Joined: Feb 26, 2005
Posts: 2057
Hi,

Will these statements pause and wait for input; i.e. proceed to next line only after an input is received?

1. ObjectInputStream.readObject()

2. BufferedReader.readLine()

Or will they immediately return something like 'null' if there is no input?
Deepak Bala
Bartender

Joined: Feb 24, 2006
Posts: 6662
    
    5

To my knowledge they are blocking calls. Try it with System.in as the inputstream.


SCJP 6 articles - SCJP 5/6 mock exams - More SCJP Mocks
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

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.


[Jess in Action][AskingGoodQuestions]
Jesus Angeles
Ranch Hand

Joined: Feb 26, 2005
Posts: 2057
I tried System.in now; and it blocked.

In the application I am looking at (hf java), for both method I mentioned above, the stream is a Socket.
[ February 17, 2007: Message edited by: Jesus Angeles ]
Deepak Bala
Bartender

Joined: Feb 24, 2006
Posts: 6662
    
    5

I went through the documentation for read() in InputStream which can be found here

http://java.sun.com/j2se/1.4.2/docs/api/java/io/InputStream.html#read()

Although the function is abstract, it looks like one has to assume that the underlying implementation will block until input data is available.

As for Sockets, a brief read of the java docs tells me that they represent "blocking" sockets. Any reference to non blocking channels throws a IllegalBlockingModeException
Jesus Angeles
Ranch Hand

Joined: Feb 26, 2005
Posts: 2057
Thanks guys. I looked at the wrong part of the doc.

Indeed, the doc on Sockets implied that if it is associated with a channel, the channel should be in blocking mode.

http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#getInputStream()
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[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 ]

"I'm not back." - Bill Harding, Twister
 
 
subject: Will these methods wait for input?