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

[Jonathan Gibbons]

javac never uses assert.    We have a set of methods in 
javac.util.Assert that can be used instead.

-- Jon


On 05/05/2014 04:18 AM, Fredrik Öhrström wrote:
> 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 <mailto: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/20140507/b5d63d91/attachment.html>