Process API Updates (JEP 102) (original) (raw)

Mark Sheppard mark.sheppard at oracle.com
Tue Mar 25 17:20:34 UTC 2014

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, 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

More information about the core-libs-dev mailing list