JEP proposal: Improved variance for generic classes and interfaces

[Dan Smith]

> On Oct 27, 2014, at 6:19 PM, elias vasylenko <eliasvasylenko at gmail.com> wrote:
> 
> There are still problems, since of course suddenly allowing contravariant overrides in one specific scenario creates situations which behave inconsistently with people's current expectations e.g.:
> 
>     class Foo implements Predicate<Integer> {
>         public boolean test(Integer value) {return false;}
>     }
> 
>     class Bar extends Foo implements Predicate<Number> {
>         public boolean test(Number value) {return true;}
>     }
> 
>     foo.test((Integer) i); // returns true instead of false when invoked on an instance of Foo!

I don't see what's wrong with just claiming Bar.test overrides Foo.test.  It would take some work to sort out the details of such a rule, but that seems to me like the clear explanation of what's "really" going on in this program.

If the programmer is upset because they really want two unrelated methods, I'm not sympathetic because the program would be malformed anyway -- a class can't have two unrelated methods that both override the same supertype method (this is enforced by 8.4.8.3, and makes sense because what would you expect when you called 'test(Object)'?).

—Dan