javac bug: Resolving conflicting defenders in interfaces

[Alex Buckley]

Interface F is even free to override get() _without giving a default_. 
As soon as F declares get() that's override-equivalent to A.get() and 
E.get(), the abstract methods A.get() and E.get() become irrelevant, as 
do their defaults.

Alex

On 10/28/2010 10:51 AM, Brian Goetz wrote:
> Here, we have interfaces with conflicting defenders, and we try and resolve 
> the conflict in a subinterface:
> 
>      private interface A {
>          public extension int get() default Implementations.one;
>      }
> 
>      private interface E {
>          public extension int get() default Implementations.two;
>      }
> 
>      private interface F extends A, E {
>          public extension int get() default Implementations.two;
>      }
> 
> test-compile:
>      [javac] Compiling 1 source file to 
> /home/brian/work/mangler/trunk/defender/build/test-classes
>      [javac] 
> /home/brian/work/mangler/trunk/defender/test/src/junit/MultipleInheritanceTest.java:25: 
> types E and A are incompatible; both define get(), but with unrelated default 
> implementations
>      [javac]     private interface F extends A, E {
>      [javac]             ^
>      [javac] 1 error
> 
> 
> I would argue this case should be allowed because F provides an unambiguous 
> default for get().  (The resolution rules say that any defender provided by F 
> "shadows" the defender provided by F's superinterfaces.)
> 
> The compiler does get this right when F is a real class and F provides an 
> implementation of get().
> 
>