JEP 102 Process Updates revised API draft

[Peter Levart]

On 03/12/2015 02:39 PM, Roger Riggs wrote:
> Hi,
>
> Just a thought, it might be useful to introduce a public subtype of 
> Process that is
> returned from ProcessBuilder for which the guarantees about behavior 
> could be
> tighter  (no UOEs).  It would also provide a place to document the 
> behaviors
> now spread across ProcessBuilder and Process.
>
> $.02, Roger
>

That was my thinking too today. A Process2 or XProcess? If ProcessHandle 
was an interface this subtype could implement it (back to square one). I 
think it could be an interface if Process2 was not publicly extendable 
(package-protected constructor) as it would not represent part of 
extensible API.

Does that mean that we would need additional methods 
ProcessBuilder.start2() / Runtime.exec2() too?

Peter

>
> On 3/12/15 9:09 AM, Chris Hegarty wrote:
>> This is looking good, still looking at the detail… just a quick comment.
>>
>> It may be possible to remove the UOE from Process.onExit, if you 
>> implement the “never to be used” default without using ProcessHandle?
>>
>> diff --git a/src/java.base/share/classes/java/lang/Process.java 
>> b/src/java.base/share/classes/java/lang/Process.java
>> --- a/src/java.base/share/classes/java/lang/Process.java
>> +++ b/src/java.base/share/classes/java/lang/Process.java
>> @@ -360,20 +360,20 @@
>>        * a unique instance is returned for each call to {@code onExit}.
>>        *
>>        * @throws IllegalStateException if the process is the current 
>> process
>> -     * @throws UnsupportedOperationException if the Process 
>> implementation
>> -     *         does not support this operation
>> -     * @implSpec
>> -     * The Process instances created by {@link ProcessBuilder 
>> ProcessBuilder} return
>> -     * a {@code ComputableFuture<Process>} equivalent
>> -     * to {@code toHandle().onExit().thenApply(ph -> this)}.
>>        *
>> -     * @implNote
>> -     * The implementation of this method is {@link #toHandle 
>> toHandle().onExit().thenApply(ph -> this)}.
>> -     * Override to provide more specific onExit behavior.
>>        * @since 1.9
>>        */
>>       public CompletableFuture<Process> onExit() {
>> -        return toHandle().onExit().thenApply((ph) -> this);
>> +        return CompletableFuture.supplyAsync(this::wait0);
>> +    }
>> +
>> +    private Process wait0() {
>> +        while(true) {
>> +            try {
>> +                waitFor();
>> +                return this;
>> +            } catch (InterruptedException x) {}
>> +        }
>>       }
>>         /**
>>
>> -Chris.
>>
>> On 11 Mar 2015, at 19:58, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>
>>> Hi,
>>>
>>> The recommendations have been applied to the javadoc and the sandbox 
>>> JDK-8046092-branch.
>>>
>>>     http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>>>
>>> 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
>>>
>