JEP 102 Process Updates revised API draft

[Chris Hegarty]

On 11/03/15 10:06, Paul Sandoz wrote:
>
> On Mar 10, 2015, at 4:41 PM, Roger Riggs <Roger.Riggs at 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.

I think this design should work out cleaner. There can be just a single 
point where UOE can be thrown, from toHandle().

My inclination, with this design, is to remove Process.getPid(), since 
the pid can be retrieved from the handle. This should be possible since 
Process.getPid() is @since 1.9.

> For arguments sake let's say we go with that approach:
>
>    public abstract class Process {

can be removed, no?
>      long getPID() throws USO { throw new USO; }

I think ProcessHandle needs a protected constructor, otherwise it cannot 
be implemented outside of the platform. Or is this the intent? In which 
case Process.getPid() may need to remain.

>      // 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.

-Chris.