JEP proposal: Improved variance for generic classes and interfaces

Remi Forax forax at univ-mlv.fr
Tue Oct 28 01:10:49 UTC 2014


On 10/28/2014 12:40 AM, Dan Smith wrote:
>> 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

see the example given by Elias, Foo requires a user defined 
implementation of test(Integer) and it's not obvious to me why Bar 
should override this method with a bridge,
i.e. a bridge can override a user defined method (for the VM) only if 
the method called by the bridge override the user define method (for 
Java the language).

Rémi



More information about the compiler-dev mailing list