Question

Consider the following code:

public interface A {
  public A another();
}

public interface B {
  public B another();
}

public interface AB extends A,B {
  public AB another();
}

This leads to a compile error on AB:

types B and A are incompatible; both define another(), but with
unrelated return types

I’ve seen this SO question, and follow the incompatibility example in the the accepted answer – i.e.

public interface C { 
  public void doSomething();
}

public interface D {
  public boolean doSomething();
}

public interface CD extends C,D { 
}

However, in that case the return types were genuinely incompatible – a return type cannot be both void and a boolean. Whereas, in my example above, the another() return type of AB is both an A and a B, so it is possible to implement both of the extended interfaces.

Furthermore, having looked at the JLS (8.4.8, 8.4.8.3, 8.4.8.4), I don’t quite understand why my example above illegal. Can anyone explain this to me?

Second, are there any solutions/workarounds to this other than repeating the contract requirements of A or B in AB?

Answer 1

This error message appears for pre 1.5 versions of Java (at least I can reproduce the error when setting the compliance level to 1.4 in Eclipse). In other words, make sure you’re looking at old-enough specs.

On Java >= 1.5 the following compiles fine.

interface A {
    public A another();
}

interface B {
    public B another();
}

interface AB extends A,B {
    public AB another();
}

As you say, since AB is both an A and a B, it satisfies both interfaces.

---

Here’s a quote from the Java Language Specification (Second Edition, i.e. Java 1.4):

9.2 Interface Members

The members of an interface are:

• Those members declared in the interface.
• Those members inherited from direct superinterfaces.
• If an interface has no direct superinterfaces, […]

It follows that it is a compile-time error if the interface declares a method with the same signature and different return type or incompatible throws clause.

Further more, the current spec says the following:

9.4.2 Overloading

If two methods of an interface (whether both declared in the same interface, or both inherited by an interface, or one declared and one inherited) have the same name but different signatures that are not override-equivalent (§8.4.2), then the method name is said to be overloaded. This fact causes no difficulty and never of itself results in a compile-time error. There is no required relationship between the return types or between the throws clauses of two methods with the same name but different signatures that are not override-equivalent.