On Mar 10, 2015, at 4:41 PM, Roger Riggs <roger.ri...@oracle.com> wrote:
> 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.
>
I still think that conflates the "OS says no" and the "Subtype of Process does
not support the contract of ProcessHandle".
Process as designed feels kind of limited and we are stuck with that.
ProcessHandle is then also limited by Process extending it. Thus my inclination
is still for Process to not extend from ProcessHandle, let's keep then at a
distance.
For arguments sake let's say we go with that approach:
public abstract class Process {
long getPID() throws USO { throw new USO; }
// Not final but effectively so for subtypes outside of package since
public construction of ProcessHandle
// is not possible
ProcessHandle toHandle() throws USO { return ProcessHandle.of(getPID()); }
CF<Process> onProcessExit() { ... } // crappy default
}
public abstract class ProcessHandle {
ProcessHandle() {}
public abstract long getPid(); // Does not throw USO
}
With such an approach if one has a ProcessHandle instance will the native PID
always be available?
Paul.
