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

[Fredrik Öhrström]

The output from stdout and stderr from the background must always be logged
into a file. The default name for that file is portfile+".stdouterr"
Thus you could replace stdouterrfile == null with

assert(stdouterrfile != null && stdouterrfile.length() >= 1)

And get rid of /dev/null etc.

For example if the background jvm cannot start, for example you supplied a
bad -Xms setting, you need to see the error message somewhere.
It is not a good idea to force the client jvm to keep running. The client
and the server must be independent.




2014-05-05 11:17 GMT+02:00 Andreas Lundblad <andreas.lundblad at oracle.com>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140505/0529e363/attachment.html>