If the second process is indeed a JVM, is that any different from spawning a Java process with a shell-script exec (something that’s quite commonly done, I assume)?
On Thursday, August 28, 2014 at 7:58 PM, roger riggs wrote: > Hi Ron, > > I have not looked at that idea closely but I would be concerned > about the robustness of the 2nd, execve'd Java runtime. Since it would > not be > a brand new process, there might be leftover state from the previous > execution that would break the usual assumptions of a newly started Java > Runtime. > Anything from signal handler state to open file descriptors to the specific > memory mapping and there may be others. > > Roger > > > On 8/26/2014 7:25 AM, Ron Pressler wrote: > > I might be a little late to this party, but recently I've had a (rather > > frustrating) need for the ability to execve a process rather than fork-exec > > it. I understand that the ability to exec (replace the current process's > > image) is also available on Windows. This operation (on ProcessBuilder?), > > which never returns, would have the same semantics as > > System.exit(pb.start().waitFor()), only it would replace the current JVM > > process (i.e. maintain the same pid/handle) with the command. > > > > This is required when a JVM process is used to set up and launch another, > > JVM or other, process, but we'd want the user running the program to be > > oblivious to the setup process (because, say, they want to monitor the > > running program with some OS tool). > > > > Ron
