JEP 102 Process Updates revised API draft

[David M. Lloyd]

On 02/13/2015 09:15 AM, Peter Levart wrote:
> On 02/13/2015 03:22 PM, Paul Sandoz wrote:
>>> >It*is*  inconvenient for the user to have to use wildcards in specifying types:
>>> >
>>> >CompletableFuture<? extends Process> cf = process.completableFuture();
>>> >
>>> >...but it doesn't hinder the use of above 'cf' quite so much as 'len' in List example above, since 'T' in CompletableFuture<T> is used mostly in co-variant positions. The only methods that use it in contra-variant positions are:
>>> >
>>> >cf.getNow(?);
>>> >cf.complete(?);
>>> >cf.obtrudeValue(?);
>>> >
>> What about the methods with a parameter type of:
>>
>>    CompletionStage<? extends T>
>>
>> such as applyToEither and acceptEither?
>>
>> Paul.
>
> Oh, I see.
>
> That's a problem, yes. And these two methods are actually very useful in
> the context of processes - waiting for 1st of two processes to finish.
>
> So the signature can only be the following:
>
>      CompletableFuture<ProcessHandle> completableFuture();

I hesitate to mention it, but as someone who has been frustrated by this 
same problem on numerous occasions I feel I must suggest that maybe... 
having a completableFuture method should just be dropped?  A user should 
be able to implement it themselves fairly easily, right?  And they'd be 
able to sidestep problems like stack size and so on by managing their 
own threads.

-- 
- DML