RFR 9: 8077350 Process API Updates Implementation Review

[Roger Riggs]

Please review clarifications and updates to the proposed Precess API.

A few loose ends in the ProcessHandle API were identified.

1) The ProcessHandle.parent() method currently returns null if the 
parent cannot
be determined and the ProcessHandle.of(PID) method returns null if the 
PID does not exist.
It has been suggested to return an Optional<ProcessHandle> to make
these methods more flexible and allow a fluent style and work better 
with streams.

2) The behavior of Processhandle.destroy and destroyForcibly are different
than Process.destroy and destroyForcibly.  Those functions always 
succeed because
they are children of the spawning process.

In contrast, ProcessHandle.destroy and destroyForcible are requests to
destroy the process and may not succeed due to operating system 
restrictions such
as the process not being a child or not having enough privilege.
The description of the methods needs to be clarified that it is a 
request to destroy
and it may not succeed, In that case the destroy and destroyForcibly 
methods
should indicate that the request was not successful.  In particular, the 
caller
may not want to wait for the process to terminate (its not going to).

The proposed update is to return an Optional<ProcessHandle> .
It can be streamed and can take advantage of the conditional operations 
on the Optional.

3) Using Optional is also attractive for the return values of the 
information
about a ProcessHandles, since not all values are available from every OS.
The returns values of Info.command, arguments, startInstant, 
totalDuration, and user
are proposed to be updated to return Optional<x>.
It allows for more compact code and fewer explicit checks for null.

Please review and comment:

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-ph/

javadoc:
    http://cr.openjdk.java.net/~rriggs/ph-apidraft/

Diffs of the spec/javadoc from previous draft:
http://cr.openjdk.java.net/~rriggs/ph-diffs-2015-05-11/overview-summary.html

Thanks, Roger