On 03/11/2015 12:51 PM, Chris Hegarty wrote:
On 11/03/15 11:34, Peter Levart wrote:
On 03/11/2015 11:29 AM, Chris Hegarty wrote:
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.
I think in majority of cases it needs not be implemented outside the
platform.
Is there any time where it would be required to implemented outside of
the platform?
Only for special implementations that don't map to local processed of
supported platforms, I think. Such as remote execution facility
disguised as a Process API. Or a facility that breaks out of sandboxed
environment for execution of local processes that are otherwise not
accessible by JVM process directly. This is all hypothetical.
> Process.getPid() can remain as a quick shortcut and by default
it can be implemented as:
public long getPid() throws USO {
return toHandle().getPid();
}
...and overridden in internal implementations with more optimal thing.
Ok, then the same can be said for Process.onExit() (which can now have a
different signature than ProcessHandle.onExit()):
public abstract class Process {
public CompletableFuture<Process> onExit() {
return toHandle().onExit().thenApply(ph -> this);
}
Are we not back where we started, since toHandle() can throw UOE?
Yes, number of such methods should be minimized. Perhaps just getPid()
since it can have much more optimal implementation in internal ProcessImpl.
Regards, Peter
-Chris.
Peter
