JEP 102 Process Updates revised API draft

[Peter Levart]

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
>