Process.waitFor(), threads, and InputStreams

I think this is slightly counter-intuitive, but:

getOutputStream Gets the output stream of the subprocess. Output to the stream is piped into the standard input stream of the process represented by this Process object. Implementation note: It is a good idea for the output stream to be buffered. Returns: the output stream connected to the normal input of the subprocess.

I read that as this Output stream from the main process and is attached to the standard input of the sub-process, so when you write to getOutputStream().write() you are actually writing on the stdin.

Do you possibly want to use .getInputStream()?

Returns: the input stream connected to the normal output of the subprocess.

As for Process.Waitfor() the API docs say:

causes the current thread to wait, if necessary, until the process represented by this Process object has terminated. This method returns immediately if the subprocess has already terminated. If the subprocess has not yet terminated, the calling thread will be blocked until the subprocess exits.

I would say the thread this is called in will be blocked until such a time as the process has finished executing - you may still be processing output at this stage depending on the other threads or they may have finished before your thread returns.

If your external process expects something on its stdin, you MUST close the getOutputStream. Otherwise you will waitFor forever.

Here is the When Runtime.exec() won't article from JavaWorld which describes different pitfalls of exec method and how to avoid them.

From my experience it's better to consume STDOUT and STDERR of child process ( until they EOF ) and then block in waitFor. Hopefully at this point you won't have to waitFor long.

An answer to Kaleb's question. Under normal conditions you shouldn't close the streams, however because you are waitingFor and for whatever reason it does not have a timeout, you may need to close these streams if you encounter some error conditions in the output and don't want to process child's output further. However, whether the child program will terminate (crash) when it's STDOUT or STDERR pipe is closed at the other end is totally up to that child's implementation. Most shell programs though, will terminate under such conditions.

I really wish waitFor had some meaningful timeout though and the Process had a documented way of cleaning up its resources when you've decided to abandon its monitoring.