A breakdown of common mistakes when working with processes

1. Deadlock when reading/writing streams

One of the nastiest issues is when a process hangs and never finishes even though it seems everything is done correctly. A common cause is overflow of the external process’s output or error buffer. If you don’t read both streams (stdout and stderr), the process can “block” when trying to write because nobody is draining its buffer.

Problem example

ProcessBuilder builder = new ProcessBuilder("java", "-version");
Process process = builder.start();
// Read only stdout and ignore stderr!
BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream()));
String line;
while ((line = reader.readLine()) != null) {
    System.out.println(line);
}
process.waitFor();

If the command writes something to stderr (for example, java -version almost always writes there!), that stream fills up, and the process hangs.

The right way

Read both streams in parallel (via separate threads or ExecutorService):

ProcessBuilder builder = new ProcessBuilder("java", "-version");
Process process = builder.start();

// Read stdout
Thread stdoutThread = new Thread(() -> {
    try (BufferedReader reader = new BufferedReader(
            new InputStreamReader(process.getInputStream()))) {
        String line;
        while ((line = reader.readLine()) != null) {
            System.out.println("[stdout] " + line);
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
});

// Read stderr
Thread stderrThread = new Thread(() -> {
    try (BufferedReader reader = new BufferedReader(
            new InputStreamReader(process.getErrorStream()))) {
        String line;
        while ((line = reader.readLine()) != null) {
            System.err.println("[stderr] " + line);
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
});

stdoutThread.start();
stderrThread.start();

process.waitFor();
stdoutThread.join();
stderrThread.join();

Takeaway:
If you don’t read stderr — the process may hang.
If you don’t read stdout — it may also hang.
Read both streams — and you’ll be fine!

2. Encoding issues

External processes may use a different text encoding for output than your Java program by default. If you don’t specify the correct encoding, you’ll get garbled text (mojibake) instead of readable output (especially noticeable with Cyrillic text).

Example of a mistake

BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream()));

This code uses the system default encoding. But if the external process writes, for example, in UTF-8 while yours is Windows-1251, Cyrillic characters will turn into gibberish.

The right way

Pass the required charset explicitly if you know it:

BufferedReader reader = new BufferedReader(
    new InputStreamReader(process.getInputStream(), StandardCharsets.UTF_8)
);

If you’re not sure, consult the program’s documentation or try several options.

Pro tip: on Windows, console utilities often use CP866 or Windows-1251, while on Linux — UTF-8.

3. Platform differences

Commands that work on one OS may be missing on another. For example, ls exists on Linux/Mac, but not on Windows (there — dir). Command syntax, path separators, and quoting differ.

Example of a mistake

ProcessBuilder builder = new ProcessBuilder("ls", "-l");
builder.start(); // On Windows: "ls" not found!

The right way

String os = System.getProperty("os.name").toLowerCase();
ProcessBuilder builder;
if (os.contains("win")) {
    builder = new ProcessBuilder("cmd", "/c", "dir");
} else {
    builder = new ProcessBuilder("ls", "-l");
}

Path to files: use File.separator instead of “/” or “\” to avoid getting tripped up by paths.

4. Permission issues

Some commands require administrator privileges (deleting system files, changing network settings, etc.). If privileges are insufficient, the command will fail or won’t start at all.

Example

ProcessBuilder builder = new ProcessBuilder("rm", "-rf", "/root/secret.txt");
Process process = builder.start();
// ... expect a Permission denied error

The right way

• Check whether elevated privileges are needed for your command.
• Handle the process return code via process.exitValue().
• Read stderr — the reason is usually there (for example, “Permission denied”).

5. Resource leaks

If you don’t close the process streams (InputStream, OutputStream, ErrorStream), they can “hang,” consume resources, and even block termination. Likewise, if you don’t terminate the process itself, it can become a “zombie” in the system.

Example of a mistake

Process process = builder.start();
// ... we work but do not close the streams!

The right way

Use try-with-resources for streams:

try (BufferedReader reader = new BufferedReader(
         new InputStreamReader(process.getInputStream()))) {
    // Read the output
}

After finishing with the process, stop it properly:

process.destroy(); // Terminate the process (if it is still alive)

Warning: if you don’t close streams, memory leaks, hangs, and system issues are possible (especially when launching many processes).

6. Deadlock in interactive communication

During interactive exchange it’s easy to end up in a deadlock: Java waits for a response, while the external process waits for your input. As a result, both are “silent.” Or you sent a message but aren’t reading the response — at some point the external program’s buffer fills up, and it stops writing.

To avoid this, separate responsibilities: one thread handles reading, the other handles writing. Then interaction proceeds in parallel, and neither side blocks the other. Also, don’t leave streams open after finishing — close them so the system doesn’t hold unnecessary resources.