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.ri...@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
>
