JEP 102 Process Updates revised API draft

[Paul Sandoz]

On Feb 13, 2015, at 1:36 PM, Peter Levart <peter.levart at gmail.com> wrote:
>>> 
>> The use of wild cards in this context is generally discouraged because it propagates to the caller as you have found out. You cannot do what you want for the same reasons you cannot do this:
>> 
>>   List<? extends Number> len = Arrays.asList(1, 2, 3);
>> 
>>   // As this point we do not know the lower bound of elements in len
>>   // Is it Integer or is it BigInteger?
>>   List<Number> ln = len;  // error
>>   ln.add(new BigInteger(...)); // Potential heap pollution
>> 
>> Which means you are stuck if you want to provide CF<Process> and CF<ProcessHandle> using the same overloaded method name.
> 
> 
> 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.