RFR: 8042088: Sjavac spawns external processes in a unnecessarily complex and platform dependent way

[Andreas Lundblad]

On Fri, May 02, 2014 at 03:01:17PM -0700, Jonathan Gibbons wrote:
> The code to use NUL or /dev/null is somewhat icky. Is that actually
> the behavior you want?
> How about using ProcessBuilder.Redirect.INHERIT instead?

I don't think we want the output of the background sjavac server to be interleaved with the output of the sjavac instance that spawned it. (Especially since the log of the background server would be chopped off once the foreground process terminates.)

The reason I can't simply leave the whole redirect logic out is because the background process halts once it's output buffer is full. The output of the background process *has* to be consumed in one way or another. I could solve this by spawning a separate thread in the foreground process whose sole purpose is to read and discand output from the background process:

    Thread discardOutputThread = new Thread() {
        public void run() {
            InputStream is = p.getInputStream();
            try { while (is.read() != -1); }
            catch (IOException e) { }
        }
    };
    discardOutputThread.setDaemon(true);
    discardOutputThread.start();

It just feels a bit awkward to leave a running dummy thread behind, and I can't find any documentation on what happens when the foreground process terminates and this thread stops. (Although it *did* work on when I tested it on Windows 2003 and Ubuntu.)

So, while the NUL or /dev/null workaround does have a grain of platform dependency, I still thought it was the cleanest solution. I'm ready to reconsider this if others think differently.

I'm somewhat surprised that there is no ProcessBuilder.Redirect.DISCARD. Does anybody know why such option is "missing"? :-(

-- Andreas