JEP 102 Process Updates revised API draft

[Roger Riggs]

Hi Peter,

On 3/12/2015 9:56 AM, Peter Levart wrote:
> 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...
Perhaps, there is some stale cache or proxy interference. I don't see 
that old version.
>
> 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?
staleness;
>
>
> 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 destroy() says that it may 
> behave in either way (forcibly or non-forcibly). How can default 
> implementation of supportsDestroyForcibly() know how existing 
> destroy() 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?
It is intended to describe the behavior of the implementation of destroy
and should limit its concrete answers to Processes returned from 
ProcessBuilder.
Though at this late stage of Process it may not be useful to anyone.
As with other extensions to the Process API without a reasonable default 
a UOE would
be more appropriate than an incorrect value.

The alternative was to introduce a destroyNormally method that would 
throw UOE
on Windows (as there is no adequate implementation).

Thanks, Roger

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