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.
