JEP proposal: Improved variance for generic classes and interfaces

[Dan Smith]

> On Oct 27, 2014, at 5:03 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> 
> On 10/27/2014 11:52 PM, Dan Smith wrote:
>>> On Oct 26, 2014, at 4:53 PM, elias vasylenko <eliasvasylenko at gmail.com> wrote:
>>> 
>>> Just a quick question/suggestion: it seems like a handy side-effect of the proposed changes is the potential for relaxation of the limitation on reimplementation of interfaces with different generic parametrisations, and I'm wondering if you've considered this.
>>> 
>>> For example, it should be possible to allow something like this:
>>> 
>>>     class Foo implements Predicate<Integer> {}
>>> 
>>>     class Bar extends Foo implements Predicate<Number> {}
>>> 
>>> Since declaration-site variance guarantees compatibility of the overriding parametrisation. Of course we can't technically override test(Integer) with test(Number)... but from an outsiders perspective I don't see this as incompatible with current language design philosophy... At any rate, covariance should be more straightforward
>>> 
>>> I'm sure this would have come up if it hasn't already, but I couldn't find any explicit mention of it.
>> That's a good idea, and not something we've looked into yet.  Thanks for the suggestion.
>> 
>> —Dan
> 
> The problem here is not a typing problem but an erasure problem, both Predicate<Integer> and Predicate<Number> require to generate a bridge method but both test(Integer) and test(Number) have the same erasure test(Object). So it's not possible without full reification to implement that bridge.

Haven't thought much about this, but can't the compiler just generate all the necessary signatures in Bar?
test(Number)Z: user's implementation
test(Integer)Z: bridge to test(Number)Z
test(Object)Z: bridge to test(Number)Z

—Dan