java - Eclipse/javac disagree on compiling signature with default method collision; who is right?

Question

Here's a simple class that demonstrates the issue:

package com.mimvista.debug;

public class DefaultCollisionTest {
    public static interface Interface1 {
        public String getName();
    }

    public static interface Interface2 {
        public default String getName() { return "Mr. 2"; };
    }

    public static <X extends Interface1&Interface2> String extractName(X target) {
        return target.getName();
    }
}

Eclipse (Neon 2) happily compiles this class while javac (JDK 1.8.0_121) spits out the following compile error:

$ javac src/com/mimvista/debug/DefaultCollisionTest.java
srccommimvistadebugDefaultCollisionTest.java:13: error: class INT#1 inherits abstract and default for getName() from types Interface2 and Interface1
        public static <X extends Interface1&Interface2> String extractName(X target) {
                       ^
  where INT#1 is an intersection type:
    INT#1 extends Object,Interface1,Interface2
1 error

I believe that Eclipse is correct in this case but I'm not totally sure. Based on my understanding of the "inherits abstract and default" error, I think it should only be generated when compiling an actual declared class that implements those two interfaces. It seems like javac may be generating an intermediate class under-the-hood to deal with that generic signature and erroneously subjecting it to the default method collision test?

Answer 1

Javac is correct according to JLS 9.4.1.3. Interfaces > Inheriting Methods with Override-Equivalent Signatures:

If an interface I inherits a default method whose signature is override-equivalent with another method inherited by I, then a compile-time error occurs. (This is the case whether the other method is abstract or default.)

The small print explains:

[...] when an abstract and a default method with matching signatures are inherited, we produce an error. In this case, it would be possible to give priority to one or the other - perhaps we would assume that the default method provides a reasonable implementation for the abstract method, too. But this is risky, since other than the coincidental name and signature, we have no reason to believe that the default method behaves consistently with the abstract method's contract - the default method may not have even existed when the subinterface was originally developed. It is safer in this situation to ask the user to actively assert that the default implementation is appropriate (via an overriding declaration).

In contrast, the longstanding behavior for inherited concrete methods in classes is that they override abstract methods declared in interfaces (see §8.4.8). The same argument about potential contract violation applies here, but in this case there is an inherent imbalance between classes and interfaces. We prefer, in order to preserve the independent nature of class hierarchies, to minimize class-interface clashes by simply giving priority to concrete methods.

Also compare with 8.4.8.4. Classes > Inheriting Methods with Override-Equivalent Signatures:

It is a compile-time error if a class C inherits a default method whose signature is override-equivalent with another method inherited by C, unless there exists an abstract method declared in a superclass of C and inherited by C that is override-equivalent with the two methods.

This exception to the strict default-abstract and default-default conflict rules is made when an abstract method is declared in a superclass: the assertion of abstract-ness coming from the superclass hierarchy essentially trumps the default method, making the default method act as if it were abstract. However, the abstract method from a class does not override the default method(s), because interfaces are still allowed to refine the signature of the abstract method coming from the class hierarchy.

In even plainer words: the assumption is that the two interfaces are logically unrelated and both specify some kind of a behaviour contract. Therefore it's not safe to assume that the default implementation in Interface2 is a valid fulfilment of the contract of Interface1. It's safer to throw an error and let the developer sort it out.

I didn't find a place in the JLS where it would exactly tackle your case, but I think the error is in the gist of the above specifications - you declare that extractName() should take an object that implements both Interface1 and Interface2. But for such an object it would only be valid if "there exists an abstract method declared in a superclass of C and inherited by C that is override-equivalent with the two methods". Your generic declaration does not specify anything about the superclass of X, so the compiler treats it as a "abstract-default" clash.