JEP 102 Process Updates revised API draft

[Roger Riggs]

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
>