Interface "gotcha"

[Malcolm Storey]

There's an Interface "gotcha" that I don't think I've read about.

If you have two method calls with the same name where the second has an argument
that is a subclass of the one in the first method, the one used at runtime will depend on
the class of the object passed as the parameter. Standard Java.

If you now put the call with the superclass argument into an interface, the subclass method will never be used.

Example:

public interface MyInterface{
       public void interfaceMethod(InterfaceArg arg);
}

public class Main {
   public static void main(String[] args) {

   SubclassOfInterfaceArg  arg = new SubclassOfInterfaceArg ();
   Whatever whatever = new Whatever();
   whatever.interfaceMethod(arg);

}

public class Whatever {

   public void interfaceMethod(SubclassOfInterfaceArg arg) {
   SystemUtil.print("Subclass Method");
   }

@Override
   public void interfaceMethod(InterfaceArg arg) {
   SystemUtil.print("Interface Method");
   }
}

With the Interface it'll print "Interface Method". Without it, it'll print "Subclass Method".

(At least, that's how it works in Eclipse).

It's not nice that adding an Interface (really just a clean way of avoiding lots of casts)
can change the execution of a program.

Surely it should either honour both methods or flag the redundant one as an error?

[Stephan van Hulst]

Everything works as expected, the subclass method should be called. It's not possible to reproduce your scenario because the code you have is not valid. Please post an SSCCE.

[Henry Wong]

Malcolm Storey wrote:
With the Interface it'll print "Interface Method". Without it, it'll print "Subclass Method".

Can you show us the "with the interface" example? As what you showed doesn't use the interface.


As for your example, when more than one method (along with the signature) match, the compiler has to figure out which one to use. It has a few ways to do this, and one of those ways is to choose the "most specific" method (which is the one that takes the subclass object).

Henry

[Malcolm Storey]

Sorry, I didn't get the example code quite right, and it won't let me edit the original question.

public interface MyInterface{
       public void interfaceMethod(InterfaceArg arg);
}

{
...
  SubclassOfInterfaceArg object = new SubclassOfInterfaceArg ();
  method(object);
...
}

 public  void method(InterfaceArg  arg) {
   Whatever whatever = new Whatever();
   whatever.interfaceMethod(arg);
}


public class Whatever {

   public void interfaceMethod(SubclassOfInterfaceArg arg) {
   SystemUtil.print("Subclass Method");
   }

@Override
   public void interfaceMethod(InterfaceArg arg) {
   SystemUtil.print("Interface Method");
   }
}

[Stephan van Hulst]

We want to be able to paste the code in our text editor, save it to a file without editing anything, and run javac.exe on it. Please google for SSCCE.

[Henry Wong]

Agreed with Stephan. The new code doesn't add anything here to clear the confusion.

Henry

[Malcolm Storey]

Sorry, third try:

public interface MyInterface {
       public void interfaceMethod(InterfaceArg arg);
}
 
{
...
  SubclassOfInterfaceArg object = new SubclassOfInterfaceArg ();
  method(object);
...
}
 
 public  void method(InterfaceArg  arg) {
   Whatever whatever = new Whatever();
   whatever.interfaceMethod(arg);
}
 
 
public class Whatever implements MyInterface {
 
   public void interfaceMethod(SubclassOfInterfaceArg arg) {
   SystemUtil.print("Subclass Method");
   }
 
@Override
   public void interfaceMethod(InterfaceArg arg) {
   SystemUtil.print("Interface Method");
   }
}

[Henry Wong]

In your first example, you passed a SubclassOfInterfaceArg instance to the interfaceMethod() of the Whatever class. This can match the signature of both methods, and hence, the compiler will choose the most specific method, which is the one that takes the Subclass argument.

In you third example, you passed an InterfaceArg instance to the interfaceMethod() of the Whatever class. This can only match one of the two overloaded methods. And hence, it calls the one that matches, which is the one that takes the InterfaceArg argument.

Henry

[Stephan van Hulst]

Malcolm, this is still not an SSCCE.

Give us something that we can copy, paste and compile.

Henry has found an answer to your problem.

[Stefan Evans]

This is a prime example of Early binding.
Decisions as to which overloaded method will be called happens at compile time
Late binding (which polymorphic version of the method gets called) happens at runtime.

Note that the interface only declares one method, while the implementation of the interface 'overloads' the interface with a new declaration.
That version of the method is only visible to a variable declared as type Whatever.

SubclassOfInterfaceArg  arg = new SubclassOfInterfaceArg();
Whatever whatever = new Whatever();
MyInterface interfaceObj = whatever

whatever.interfaceMethod(arg); 
// will bind to Whatever.interfaceMethod(SubclassOfInterfaceArg);

interfaceObj.interfaceMethod(arg);
/* will bind to MyInterface.interfaceMethod(InterfaceArg), which gets
 * resolved at runtime to Whatever.interfaceMethod(InterfaceArg)
 * as the implementation to run
 */

[Stefan Evans]

Oh, and here is an SCCE demonstrating the 'issue' as I understand it.

package com.test.binding;

import org.junit.Test;


public class EarlyBindingLateBindingExample {

  interface MyInterface {
    void overloadedMethod(ParentClass c);
  }

  public class MyImpl implements MyInterface {
    @Override
    public void overloadedMethod(ParentClass c) {
      System.out.println("Calling method that takes parent class with " + c.toString());
    }

    public void overloadedMethod(ChildClass c) {
      System.out.println("Calling method that takes child class with " + c.toString());
    }
  }

  public class ParentClass {

    @Override
    public String toString() {
      return "Parent Class Object";
    }
  }

  public class ChildClass extends ParentClass {

    @Override
    public String toString() {
      return "Child Class Object";
    }
  }

  @Test
  public void demonstrateEarlyBinding() {
    ParentClass parentObj = new ParentClass();
    ChildClass childObj = new ChildClass();
    ParentClass parentWithChildAssigned = new ChildClass();
    
    MyInterface example = new MyImpl();
    example.overloadedMethod(parentObj);
    example.overloadedMethod(childObj);
    example.overloadedMethod(parentWithChildAssigned);
    
    MyImpl implExample = new MyImpl();
    implExample.overloadedMethod(parentObj);
    implExample.overloadedMethod(childObj);
    implExample.overloadedMethod(parentWithChildAssigned);
    
  }
}

The results of running (with the difference highlighted) are:

Calling method that takes parent class with Parent Class Object
Calling method that takes parent class with Child Class Object
Calling method that takes parent class with Child Class Object

Calling method that takes parent class with Parent Class Object
Calling method that takes child class with Child Class Object
Calling method that takes parent class with Child Class Object

[Malcolm Storey]

Thanks guys, that makes sense now. I was concentrating too much on the view from the class/method and ignoring its calling context.

[Ashwin Rao]

Stefan Evans wrote:Oh, and here is an SCCE demonstrating the 'issue' as I understand it.

package com.test.binding;

import org.junit.Test;


public class EarlyBindingLateBindingExample {
           //Your Code Here
}

How does your program work? It has no main method! :|
I haven't seen code like yours before.

[Jesper de Jong]

Ashwin, Stefan's code is written as a JUnit test.

JUnit is a very widely used tool for writing unit tests.

[Junilu Lacar]

Ashwin Rao wrote:
How does your program work? It has no main method! :|
I haven't seen code like yours before.

JUnit or something like it needs to be in every programmer's arsenal of development tools. In fact, you should have a test class for every production class you write. I will go even further and say that you should write some test code before you write any line of production code. If you haven't used JUnit yet, you'd be well advised to start learning how to use it as soon as possible.

[RANT ]
I find it mind-boggling that with all the information available online and in print, there seems to be a disproportionately large number professional developers out there who don't know how to unit test versus those who do. And based on the kind of questions we see in these forums and the dearth of activity in the Testing forum, I just can't fathom why it seems that new programmers aren't being taught about unit testing at all!

One of the first things you are taught when you learn how to drive is how to use your seatbelt. Then you're taught a bunch of other things, mostly related to operating the vehicle safely. In programming, learning how to use a unit test harness like JUnit is like learning how to be a safe driver. I think we really need a catchy slogan like "Click it or ticket!" in our field. "Test it or debug it!" just doesn't have that same kind of ring to it though... I don't know maybe it will grow on me.
[/RANT]

[Stefan Evans]

I'll admit to being lazy.
I could have put a public static void main method, instantiated the object and called the testing method explicitly.
In fact I used to do that quite a lot when I wanted to test bits and pieces. But that ended up with a significant amount of "boilerplate" code - particularly if I then put in a try/catch to print exceptions.

Putting the @Test annotation on the method is easier, and gives you the functionality to test throwaway code without needing excessive amounts of boilerplate.