JEP 102 Process Updates revised API draft

[Peter Levart]

On 03/12/2015 09:41 PM, Roger Riggs wrote:
> 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

That's right. The delegation approach with unrelated Process / 
ProcessHandle seems to be the most clean from API perspective.

Regards, Peter

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