Use of super in type parameters

[Alex Buckley]

As someone once said, "There is literally no end to the features people 
can suggest for Java."

This particular feature was suggested in 2004 and not taken forward 
(http://bugs.sun.com/view_bug.do?bug_id=5052956). Maybe one day generics 
will be overhauled and regularized, but it will take a JSR to do it (as 
JSR 335 does for inference).

Alex

On 4/17/2013 2:53 PM, Martin Buchholz wrote:
> With the coming of lambda, it is more likely that people will be
> creating APIs with "not quite correct" generic types, as we are doing in
> CompletableFuture.  Which is pretty bad for a feature that is designed
> specifically to provide compile time safety.  It would be nice to at
> least have an acknowledgment that there is a problem here, even if it
> will not be fixed for this release.
>
>
> On Mon, Apr 15, 2013 at 12:50 PM, Zhong Yu <zhong.j.yu at gmail.com
> <mailto:zhong.j.yu at gmail.com>> wrote:
>
>     I have encountered on stackoverflow.com <http://stackoverflow.com>
>     several legit use cases of
>     lower bound. And the other day Ali Lahijani raised the question that
>     Stream.reduce(BinaryOperator) breaks convariance of Stream, and I
>     thought that the root problem is lack of lower bound - the method
>     would have had a better signature
>          Stream<T>
>              <U super T> Optional<U> reduce(BinaryOperator<U> accumulator)
>     So I don't think there's a lack of use cases for lower bound. (But I
>     have no idea how difficult it is to support it)
>
>     Zhong Yu
>
>
>     On Mon, Apr 15, 2013 at 2:37 PM, Martin Buchholz
>     <martinrb at google.com <mailto:martinrb at google.com>> wrote:
>      > CompletableFuture currently has a method like this:
>      >
>      >     public CompletableFuture<Void> acceptEither
>      >         (CompletableFuture<? extends T> other,
>      >          Consumer<? super T> block) {
>      >         return doAcceptEither(other, block, null);
>      >     }
>      >
>      > But that signature is not quite correct (not as general as it
>     could be).
>      >  The "correct" signature is
>      >
>      >     public <U super T> CompletableFuture<Void> acceptEither
>      >         (CompletableFuture<? extends U> other,
>      >          Consumer<U> block) {
>      >         return doAcceptEither(other, block, null);
>      >     }
>      >
>      > but that fails to compile, because type parameters can only be
>     constrained
>      > by extends, not super.  Is implementing this on the radar?
>       Angelika claims
>      > "lower bounds for type parameters make no sense"
>      >
>     http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#Why%20is%20there%20no%20lower%20bound%20for%20type%20parameters
>      > ?
>      >
>      > but I am finding that hard to believe.  Is she right? For
>     comparison,  the
>      > equivalent static method can be made to do what we want:
>      >
>      >     public static <U> CompletableFuture<Void> acceptEither
>      >         (CompletableFuture<? extends U> f,
>      >          CompletableFuture<? extends U> other,
>      >          Consumer<U> block) {
>      >         return ...
>      >     }
>
>