Process API Updates (JEP 102)

[Ron Pressler]

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