On Feb 13, 2015, at 1:36 PM, Peter Levart <peter.lev...@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.
