Process API Updates (JEP 102)

[Peter Levart]

On 03/24/2014 10:11 PM, roger riggs wrote:
> Hi,
>
> I'm starting to work on JEP 102, Process API Updates for JDK 9.
> The use cases identified include test execution and build systems such
> as Jtreg and Hudson/Jenkins. And there is a use-case for using Java
> to monitor the health of a more complex system where the processes
> are not spawned by the same manager.
>
> The current API of Process itself is pretty complete with the addition 
> of a getPid
> method to enable identification of subprocesses spawned by the 
> application
> and allow external identification.  It will not be possible to 
> intercept the input,
> output and error streams of an arbitrary process.
>
> From the scope of the JEP, a fairly simple API seems sufficient.
>  - Enumerate the direct children

What about self? An application might want to communicate it's own PID 
to some other process (write it into a file, for example). Other Process 
API methods are not sensible for "self" process so this might as well be 
just simple static getSelfPid() method.

>  - The rest of the functions are similar to Process
>    - to terminate a process, forcibly and normally
>    - to destroy a process and all of its children recursively
>    - to check if one is alive
>    - to waitFor for termination and retrieve the exit status
>
> Are there use cases for which this is insufficient?  Please comment.

It would be nice if this new API interoperated with old Process API in a 
way that using both interchangeably for the same child process would be 
possible. For example: spawning a child with old Process API and 
enumerating/waiting/checking it with new API in some thread while 
waiting for termination using old API in another thread...

I wonder if an approach to just add getPid() (and maybe some other 
method) to old Process class together with some static methods to 
enumerate child processes would be possible?

It would just require the API specification to strengthen it's 
guarantees on some methods: for example destroyForcibly() would 
guarantee forcible termination. It might require an additional method 
like destroyNicely() or terminateNicely() which would guarantee a kind 
of termination where victim process could clean-up. The specification 
already allows getInputStream()/getOutputStream()/getErrorStream() to 
return special "null streams" when spawned process IO is redirected 
to/from file. The enumeration methods could simply return Process object 
which would:

- be same instances of Process objects created with ProcessBuilder API 
for processes spawned by the Process API. This would require an internal 
registry of live Process objects. We already have reaper threads which 
could be used to clean-up this registry on process termination.
- be new Process objects for child processes spawned in some other way 
(or by children) and which would return special "null streams" from 
their getInputStream()/getOutputStream()/getErrorStream() methods. These 
Process objects could be instantiated lazily on first request and then 
registered in the same internal registry. They might still require 
reaper threads to enable waiting on them from multiple Java threads and 
cleaning-up registry, but they could probably be created lazily.

The worst thing is to have an entirely separate API that does not 
interoperate with old API. I think the old API is not so bad. It just 
lacks some features and it's implementation could be revamped a bit.

What do you think?

Regards, Peter

>
> Thanks, Roger
>