Calling same method name from two different interface - Java

Question

Java doesn't allow the multiple inheritance to protect diamond problem. It uses interface to take care of this problem.

Then the case of using interface, let's say

interface A{
run();
}

interface B{
run();
}

class C implements A, B{
run() {}   //Which interface we are using?
}

When we call the method run() in the class C, how can we determine which interface we are using?

Answer 1

You don´t. And it does not matter, since the implementation is not on the interface but on the class. So the implementation is unique. No ambiguity.

What does matter is if each declaration wants to have a different return type:

interface A{
    void run();
}

interface B{
    String run();
}

class C implements A, B{
    ???? run() {}
}

This is the only way you can have problems with multiple interfaces in Java.

Answer 2

It does not matter. The purpose of the interface is to indicate that the class C has a method run(). You can depend on that method being there.

Even though both A and B specify the run method it is only implemented once so there is no conflict.

When you say you are using an interface it really means how your objects are declared:

   A myobject = new C();
   myobject.run();

vs

   B myObject = new C();
   myobject.run();

In the first case you are "using" the A interface, that is, your code is assuming that the myobject Object is of type A and that it has a method called run(). In the second case you are "using" the interface B.

Answer 3

If a type implements two interfaces, and each interface define a method that has identical signature, then in effect there is only one method, and they are not distinguishable. If, say, the two methods have conflicting return types, then it will be a compilation error. This is the general rule of inheritance, method overriding, hiding, and declarations, and applies also to possible conflicts not only between 2 inherited interface methods, but also an interface and a super class method, or even just conflicts due to type erasure of generics.

Compatibility example

Here's an example where you have an interface Gift, which has a present() method (as in, presenting gifts), and also an interface Guest, which also has a present() method (as in, the guest is present and not absent).

Presentable johnny is both a Gift and a Guest.

public class InterfaceTest {
    interface Gift  { void present(); }
    interface Guest { void present(); }

    interface Presentable extends Gift, Guest { }

    public static void main(String[] args) {
        Presentable johnny = new Presentable() {
            @Override public void present() {
                System.out.println("Heeeereee's Johnny!!!");
            }
        };
        johnny.present();                     // "Heeeereee's Johnny!!!"

        ((Gift) johnny).present();            // "Heeeereee's Johnny!!!"
        ((Guest) johnny).present();           // "Heeeereee's Johnny!!!"

        Gift johnnyAsGift = (Gift) johnny;
        johnnyAsGift.present();               // "Heeeereee's Johnny!!!"

        Guest johnnyAsGuest = (Guest) johnny;
        johnnyAsGuest.present();              // "Heeeereee's Johnny!!!"
    }
}

The above snippet compiles and runs.

Note that there is only one @Override necessary!!!. This is because Gift.present() and Guest.present() are "@Override-equivalent" (JLS 8.4.2).

Thus, johnny only has one implementation of present(), and it doesn't matter how you treat johnny, whether as a Gift or as a Guest, there is only one method to invoke.

Incompatibility example

Here's an example where the two inherited methods are NOT @Override-equivalent:

public class InterfaceTest {
    interface Gift  { void present(); }
    interface Guest { boolean present(); }

    interface Presentable extends Gift, Guest { } // DOES NOT COMPILE!!!
    // "types InterfaceTest.Guest and InterfaceTest.Gift are incompatible;
    //  both define present(), but with unrelated return types"
}

This further reiterates that inheriting members from an interface must obey the general rule of member declarations. Here we have Gift and Guest define present() with incompatible return types: one void the other boolean. For the same reason that you can't an void present() and a boolean present() in one type, this example results in a compilation error.

Summary

You can inherit methods that are @Override-equivalent, subject to the usual requirements of method overriding and hiding. Since they ARE @Override-equivalent, effectively there is only one method to implement, and thus there's nothing to distinguish/select from.

The compiler does not have to identify which method is for which interface, because once they are determined to be @Override-equivalent, they're the same method.

Resolving potential incompatibilities may be a tricky task, but that's another issue altogether.

References

http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.8.4

Answer 4

Even if you implement multiple interfaces with same method declarations, you will only have one definition of that method in your class. So, there isn't any ambiguity here since there is only one method to call.

Answer 5

You can't tell; however it doesn't matter either, as interfaces have no functionality.

This will change slightly when Java 8 comes out as then interfaces can have default implementations of functions; if there's more than one default implementation then there might be ambiquity. How this is solved is explained in the question Are defaults in JDK 8 a form of multiple inheritance in Java?.

Answer 6

Your question doesn't make much sense. Let's take a realistic example. A Human can cry. An AnimalBaby can cry. Now you have an instance John which is both a Human and an AnimalBaby, and you make it cry. What happens? John cries. The fact that it implements the cry() methods of both interfaces doesn't change what crying means and does for John.

Answer 7

Both. C inherited two methods from two interfaces (which happen to be override-equivalent (8.4.8.4)). C then have one method that overrides both because the signature matches both. (8.4.2)

However, one could wonder - just because two methods have the same name and parameter types, does not necessarily mean they have the same semantics. The name could very well be one english word that means two different things. What if we inherited two methods from two super interfaces that look the same but are actually different in semantics, therefore there should be two implementations in the subclass? For example

interface java.lang.Runnable
    void run()

interface com.animal.Runnable
    void run()

class Dog implements com.animal.Runnable,
                     java.lang.Runnable // a dog as a task
    ???

We can imagine a language that can handle such cases. But Java does not do that. If two methods are similar enough, they are assumed to have the same semantics. Fortunately in practice this does seems to be a problem anyway.