JEP 102 Process Updates revised API draft

[Peter Levart]

On 03/11/2015 11:06 AM, Paul Sandoz wrote:
>> >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 too like this design better.

>
> 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()); }

Not possible to have custom implementations of ProcessHandle (the 
constructor is package-private), but possible to construct the internal 
implementation (ProecssHandle.of(pid)). Which means that external 
implementations based on local OS processes on supported platforms can 
still override Process.toHandle() and return an internal implementation. 
A quick scan on external implementations shows that they are usually 
just wrappers over JDK provided Process and even if they are not, the 
internal ProcessHandle implementation can be compatible with them as it 
doesn't do anything exclusive with the OS process it represents except 
obvious things like killing it and so, which is possible from outside 
JVM too.

>
>      CF<Process> onProcessExit() { ... } // crappy default

I don't know. There are two ways to get that behaviour then. 
Process.onProcessExit() and Process.toHandle().onExit(). If Process is 
not a subtype of ProcessHandle, we can skip this method, since you can 
always do the following:

Process p = ...
p.toHandle().onExit(ph -> { ... use captured p directly ... });

>    }
>
>    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?

I think it should be, since ProcessHandle implementation is 
internal-only and getPid() is available on supported platforms.

>
> Paul.