Just curious, how is Process’s std in/out/err streams a problem?
The documentation does say that it is recommended to use buffered inputstreams. Also the documentation for BufferedReaders read() states the conditions which it checks for so that it does not block. So there is no need for multiple threads.
It does of course require some fixture code to actually use the streams, but other than that I see little problems with that part of the Process class. Perhaps except for a possible memory issue, as stated @fanf.
The ProcessBuilder, on the other hand, is some degree of terrible in my oppinion. I much more like the Runtime.exec() methods, they are clean and simple.
Also I think the ProcessBuilder has a design fault, in my opinion. The builder and its data is not immutable. That means some thread or code could change the attributes of the processbuilder and hence introduce unwanted changes into the child-process creation process. Because it acts as a template, it can be changed whenever, and it might not be very visible when and what has changed.
I am non to fond of the java 9 ProcessHandler concept either. It seems to me to be abstraction upon abstraction, which makes it difficult to reason with.
I can imagine a much simpler Process (ProcessBuilder) class than what exists in the jdk and NuProcess, which can be wrapped by a several different classes to extend the basic Process class and in the end wrapped by a scala Process class. But I get ahead of my self.