Hi again, I figured out and err deserve a null-check test as well. See patch. I'm wondering, if or how a similar check could be applied as well to ToolProvider.run(PrintWriter, PrintWriter, String...) which currently is implemented (hopefully) by each tool having to repeat the null-checks. I'm also wondering about the call to flush in run(PrintStream out, PrintStream err, String... args). It looks like the intention was to flush the wrapping PrintWriter. That is not possible without also flushing the underlying PrintStream. BufferedWriter.flushBuffer would be a more sensible method to call but is not accessible. The effect is actually, that the call to PrintWriter.flush will also call flush of the underlying PrintStream. Should that be documented more explicitly, for example: diff -r 7c17199fa37d src/java.base/share/classes/java/util/spi/ToolProvider.java --- a/src/java.base/share/classes/java/util/spi/ToolProvider.java Fri Feb 15 08:21:08 2019 -0500 +++ b/src/java.base/share/classes/java/util/spi/ToolProvider.java Sat Feb 16 09:17:46 2019 +0100 @@ -107,6 +107,8 @@ * @implNote This implementation wraps the {@code out} and {@code err} * streams within {@link PrintWriter}s, and then calls * {@link #run(PrintWriter, PrintWriter, String[])}. + * Both {@code out} and {@code err} streams are flushed before the method + * returns as a side-effect of flushing the wrapping {@link PrintWriter}s. * * @param out a stream to which "expected" output should be written * Regards, Philipp