JEP 102 Process Updates revised API draft

[Roger Riggs]

Hi Paul,

On 3/10/2015 11:22 AM, Paul Sandoz wrote:
>
>>> Any sub-type of Process that does not override getPid will essentially result in that USO being propagated to many ProcessHandle methods that depend on the PID (parent, children, allChildren, info, compareTo). That effectively renders ProcessHandle almost useless for sub-types outside of our control that that not been updated.
>> For those methods, the default behavior can be specified, except for compareTo
>> they already have return values that allow for the fact that the information may
>> not be available, either due to OS restrictions (permissions) or is not provided.
>> Empty lists for children, nulls returned from info, and even allowing for an unavailable parent.
> That's a separate issue.
>
> If i get a ProcessHandle given to me, i do not know it's source, i dunno if it's gonna barf if i operate on it.
It can be a goal to never throw UOE, to achieve that, the behaviors of 
all of the methods
(of Process) would be defined to have outputs that have to be checked by 
the app;
hence the reference to nulls; empty lists, etc.

In many cases already, if the OS does not provide values or the OS 
permissions do not permit
it then the values returned are empty (instead of throwing exceptions).
That design can be extended to the external subclasses by specifying the 
default behavior
of Process and then defining the behaviors of Processes created by 
ProcessBuilder.

Roger