JEP proposal: Improved variance for generic classes and interfaces

[elias vasylenko]

> 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)'?).

I think I tend to agree with this. Seems like the behaviour would also be
consistent for something like the following, where the erased signature of
the overridden 'multitest' would be identical in Foo and Bar anyway:

    public interface Predicate<? super T> {
        boolean test(T t);

        default boolean multitest(Collection<? extends T> t) {/*...*/}
    }

On 28 October 2014 05:44, Dan Smith <daniel.smith at oracle.com> wrote:

> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20141028/c6f3148a/attachment.html>