Hi Peter,
Introducing a public Process subtype would not be a binary compatible
change;
the return type of ProcessBuilder.start can not be narrowed.
As you surmised, a different start method would be needed on ProcessBuilder.
Since ProcessBuilder is the preferred mechanism to created processes, I
would
leave Runtime.exec alone to avoid a proliferation of similar methods.
If ProcessHandle were an interface, Process would still have the
conflict over the
return type of onExit() since CompletableFuture<Process> is not type
compatible
with CF<ProcessHandle>. So not quite the winning combination to enable
polymorphism.
Roger
On 3/12/2015 10:38 AM, Peter Levart wrote:
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
