How was one method chosen over another in this code?

Question

This is another SCJP question. The code below prints Alpha:fooBeta:fooBeta:barBeta:bar , and I don't understand why the first call to foo chose Alpha foo instead of the beta. If the Alpha.foo parameter is changed to String instead of String ..., then the output will be Beta:fooBeta:fooBeta:barBeta:bar , which makes sense.

I understand that when you say Alpha a = new Beta(); , the compiler checks Alpha.foo, but the JVM actually launches Beta.foo. First, Beta has a foo method whose signature matches the call. For another, I thought that varargs methods only execute when there is no other method available that matches the call. Therefore, for two reasons, I believe that Alpha.foo should not start. What part of this understanding is wrong?

Thanks!

 class Alpha { public void foo(String... args) { //if this were String args, then it makes sense System.out.print("Alpha:foo"); } public void bar(String a) { System.out.print("Alpha:bar"); } } public class Beta extends Alpha { public void foo(String a) { System.out.print("Beta:foo"); } public void bar(String a) { System.out.print("Beta:bar"); } public static void main(String[] arg) { Alpha a = new Beta(); Beta b = (Beta) a; a.foo("test");//confusing line b.foo("test"); a.bar("test"); b.bar("test"); } } 

Edit: I think I know where I misunderstood right now. I thought in a situation SuperClass sc = new SubClass(); any method that is called in sc will search in SubClass at run time, although at compile time they will be executed in SuperClass. It turns out, as I now think, I understand that any method called sc will look in SuperClass both at compile time and at runtime, UNLESS SubClass has provided a "better" version of the method. Then, even during compilation, the compiler will know that the method to call is the version of SubClass.

Answer 1

Method overloading is implemented at compile time, method overriding is implemented at runtime.

In your case, foo in Beta does not override foo in Alpha. He overloads it with various arguments (this can be proved by adding the @Override annotation, which is best practice for detecting such less obvious potential problems).

Another hidden thing is that you cannot call Alpha#foo(..) from the Beta link - ie b.foo("test") will always call the non-varargs method. Because of what this is happening, see this question.

Answer 2

The method with the String[] or String... parameters and the method with the String parameter do not have a single signature. A string array is a completely separate type, so standard overloading and polymorphism do not occur. The compiler sees an instance of type Alpha and calls the foo method found there. The foo method is not called in beta because it is not really an override of the Alpha version.

(The @Override annotation is used @Override . If you try to use it in the beta version of foo , you will get a compiler error.)

Answer 3

Since the a and b methods "foo ()" do not have the same signature, the b () method does not cancel the foo () method.

For this reason, when you call "a.foo ()", Alpha.foo ().

To make sure you can try putting the @Override annotation in the "b.foo ()" method. This will result in a compilation error (since "b.foo ()" does not cancel anything).

Answer 4

When you say Super a = new Sub (); and do a.methodCall (); The following rule applies.

See if the subclass of the class has a method that overrides the method in the superclass and calls it.

But here the method in the subclass does not override, but overloads the method in super, so the implementation of the superclass is called. When you make the arguments for the two methods the same. Then the principle of redefinition is applied.

Answer 5

Switching occurs at runtime, here in your case you do not override the foo method, since the parameters of the methods in the superclass and subclass are different. A method with the String[] or String... parameter and a method with the String parameter is not the same.