On 03/11/2015 08:58 PM, Roger Riggs wrote:
Hi,
The recommendations have been applied to the javadoc and the sandbox
JDK-8046092-branch.
http://cr.openjdk.java.net/~rriggs/ph-apidraft/
That's strange. Process no longer extends ProcessHandle (which is
visible in apidraft), but ProcessHandle still lists Process as it's
direct subclass...
Also, the implementation note of Process.onExit() says:
Implementation Note:
The implementation of this method is
|toHandle().onExit().thenApply(ph -> this)|
<http://cr.openjdk.java.net/%7Erriggs/ph-apidraft/java/lang/Process.html#toHandle-->.
Override to provide more specific onExit behavior.
...but there is no ProcessHandle.onExit() (there is a
ProcessHandle.completableFuture()). Looks like Process and ProcessHandle
are from different stories?
Otherwise the Process API is now in a shape that is acceptable, I think,
except the following:
public boolean supportsDestroyForcibly()
Returns |true| if the implementation of |destroy()|
<http://cr.openjdk.java.net/%7Erriggs/ph-apidraft/java/lang/Process.html#destroy-->
is forcible. Forcible process destruction is defined as the immediate
termination of a process. Returns |false| if the implementation of
|destroy| allows a process to shut down cleanly.
Returns:
|true| if the implementation of |destroy()|
<http://cr.openjdk.java.net/%7Erriggs/ph-apidraft/java/lang/Process.html#destroy-->
is forcible; otherwise |false|
Since:
1.9
So this is a new method that reports how existing pre-JDK8 method
(destroy()) behaves, but specification for destory() says that it may
behave in either way (forcibly or non-forcibly). How can default
implementation of supportsDestroyForcibly() know how existing destory()
behaves int external implementations?
Or was it meant for supportsDestroyForcibly() to describe behaviour of
destroyForcibly() which is @since JDK8? In that case the specification
of supportsDestroyForcibly() can only guarantee that 'true' result is
correct. Default implementation must return 'false' and specification
must say that this method may return false negative. Do you agree?
Regards, Peter
Some operations on a Process take an extra dereference due to the
delegation to ProcessHandle.
For example, getting the cputime or startTime of the process:
Process p = ...
Duration d = p.toHandle().info().totalCpuDuration();
Instant start = p.toHandle().info().startInstant();
As do the listing of children; convenience methods could be introduced
with the UOE possibility
but that is a risk only for externally defined Process subtypes.
Developers working with Processes should not have to deal with
ProcessHandle
to get information about the processes they spawn.
Comments appreciated, Roger
