Process API Updates (JEP 102)

[Mark Sheppard]

Hi Roger,
    I have a few questions for your consideration, hopefully they make 
sense!

Is this API to be available to the plug-in/applet? Even with appropriate 
permissions?
What permissions are required to invoke operations on the API?

Do you need to differentiate between "spawning" a Java process and a 
process that will execute
a non Java executable?

Is this part of the model?

If a Java subprocess is created should it be "instrumented" with a 
remote control interface object
to enable "fine grained" process control?

Is the current Process abstraction to remain or be depecrated?

If it remains why not extend its API rather introduce a second abtraction?

Will the Runtime and ProcessBuilder be adapted to new ProcessHandle 
abstraction?
i.e.they will return ProcessHandle?

Why not refactor the Process abstraction to be a final class rather than 
an abstract class
as part of this work?

ProcessHandle.children() returns a Stream<ProcessHandle>, why not return 
a Collection and the Stream can be
obained from the Collection?

What will the children method return when invoked on the ProcessHandle 
of a subprocess?
   the subprocesses may, in turn, have subprocesses but they will not be 
known within
the context of the parent.

What should be the security and permission model for invoking a destroy 
operation?

What about encapsulating additional information in ProcessHandle, e.g. 
uid or owner,
start time, process name, target executable

If it is possible to invoke
ProcessHandle somePidPh = ProcessHandle.get(somePid), where pid is an 
arbitrary value
then what will happen
if an attempt is made to subsequently invoke 
somePidPh.destroyForcibly(). somePidPh is not
a sub-process of the invoker. should it just silently fail?
Or to re-phrase, how will the OS level restrictions on killing a process 
be encapsulated in the
ProcessHandle model?

Are the ProcessHandles of all processes created within a single JVM 
available to all threads with
that JVM, or is there to be any levels of isolation and visibility 
imposed within the calling JVM?

WRT waitFor() method could take "callback argument" which is invoked 
when the sub-processed is finally reaped?

regards
Mark
On 24/03/2014 21:11, 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
>  - 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.
>
> Thanks, Roger
>