Overloading is compile-time polymorphism. Really?

Question

I do know the syntactical difference between overriding and overloading. And I also know that overriding is run-time polymorphism and overloading is compile-time polymorphism. But my question is: "Is overloading is really compile-time polymorphism? Is the method call really solving at compile time?". To clarify my point, let's consider an example class.

public class Greeter {
    public void greetMe() {
        System.out.println("Hello");
    }

    public void greetMe(String name) {
        System.out.println("Hello " + name);
    }

    public void wishLuck() {
        System.out.println("Good Luck");
    }
}

Since all of the methods greetMe(), greetMe(String name), wishLuck() are public, they all can be overriden(including overloaded one), right? For example,

public class FancyGreeter extends Greeter {
    public void greetMe() {
        System.out.println("***********");
        System.out.println("*  Hello  *");
        System.out.println("***********");
    }
}

Now, consider the following snippet:

Greeter greeter = GreeterFactory.getRandomGreeter();
greeter.greetMe();

The getRandomGreeter() method returns a random Greeter object. It may either return an object of Greeter, or any of its subclasses, like FancyGreeter or GraphicalGreeter or any other one. The getRandomGreeter() will create the objects either using new or dynamically load the class file and create object using reflection(I think it is possible with reflection) or any other way that is possible. All of these methods of Greeter may or may not be overriden in subclasses. So the compiler has no way to know whether a particular method(overloaded or not) is overriden. Right? Also, wikipedia says on Virtual functions:

In Java, all non-static methods are by default "virtual functions". Only methods marked with the keyword final, which cannot be overridden, along with private methods, which are not inherited, are non-virtual.

Since, virtual functions are resolved at run-time using dynamic method dispatch, and since all non private, non final methods are virtual(whether overloaded or not), they must be resolved at run-time. Right?

Then, How can overloading still be resolved at compile-time? Or, is there anything that I misunderstood, or am I missing?

Series

Answer 1

Overloaded methods can still be overridden, if that is what you ask.

Overloaded methods are like different families, even though they share the same name. The compiler statically chooses one family given the signature, and then at run time it is dispatched to the most specific method in the class hierarchy.

That is, method dispatching is performed in two steps:

• The first one is done at compile time with the static information available, the compiler will emit a call for the signature that matches best your current method parameters among the list of overloaded methods in the declared type of the object the method is invoked upon.
• The second step is performed at run time, given the method signature that should be called (previous step, remember?), the JVM will dispatch it to the most concrete overridden version in the actual type of receiver object.

If the method arguments types are not covariant at all, overloading is equivalent to having methods names mangled at compile time; because they are effectively different methods, the JVM won't never ever dispatch them interchangeably depending on the type of the receiver.

Kataway

I know that overloaded methods can be overriden. But how do compile-time polymorphism applied to overloaded methods? They also can be overriden, and therefore must be resolved at run-time. Right? – Series

Could you please explain this family thing some more? – Series

Jomoos: the compiler can still resolve which of the overloaded methods to choose at compile time, because the argument list cannot change with overriding. At runtime, the JVM just resolves from which object it should call this "version" (selected from the overloaded versions at compile time) of the method. Excuse the layman's terms, I do not have a deep CS background. – Saberio

Answer 2

Every 'Greeter' class has 3 virtual methods: void greetMe(), void greetMe(String), and void wishLuck().

When you call greeter.greetMe() the compiler can work out which one of the three virtual methods should be called from the method signature - ie. the void greetMe() one since it accepts no arguments. Which specific implementation of the void greetMe() method is called depends on the type of the greeter instance, and is resolved at run-time.

In your example it's trivial for the compiler to work out which method to call, since the method signatures are all completely different. A slightly better example for showing the 'compile time polymorphism' concept might be as follows:

class Greeter {
    public void greetMe(Object obj) {
        System.out.println("Hello Object!");
    }

    public void greetMe(String str) {
        System.out.println("Hello String!");
    }
}

Using this greeter class will give the following results:

Object obj = new Object();
String str = "blah";
Object strAsObj = str;

greeter.greetMe(obj); // prints "Hello Object!"
greeter.greetMe(str); // prints "Hello String!"
greeter.greetMe(strAsObj); // prints "Hello Object!"

The compiler will pick out the method with the most specific match using the compile-time type, which is why the 2nd example works and calls the void greetMe(String) method.

The last call is the most interesting one: Even though the run-time type of strAsObj is String, it has been cast as an Object so that's how the compiler sees it. So, the closest match the compiler can find for that call is the void greetMe(Object) method.

Buttonhole

Is there a way to make greeter.greetMe(strAsObj); print Hello String? In other words, is there a way to do runtime polymorphism? – Tricot

Answer 3

What is polymorphism?

Acc. to me: if an entity can be represented in more than one forms, that entity is said to exhibit polymorphism.

Now, lets apply this definition to Java constructs:

1) Operator overloading is compile time polymorphism.

For example, + operator can be used to add two numbers OR to concatenate two strings. it's an example of polymorphism strictly saying compile-time polymorphism.

2) Method overloading is compile time polymorphism.

For example, a method with same name can have more than one implemntations. it's also a compile-time polymorphism.

It's compile-time because before execution of program compiler decides the flow of program i.e which form will be used during run-time.

3) Method overriding is run-time polymorphism.

For example, a method with same signature can have more than one implemenations. it's a run time polymorphism.

4) Base class use in place of derived class is run time polymorphism.

For example, an interface reference can point to any of it's implementor.

It's run-time because the flow of program can't be known before execution i.e. only during run-time it can be decided that which form will be used.

I hope it clears a bit.

Pleat

Answer 4

Overloading in this respect means that the type of the function is statically determined at compile time as opposed to dynamic dispatch.

What really happens behind the scenes is that for a method named "foo" with types "A" and "B" two methods are created ("foo_A" and "foo_B"). Which of them is to be called is determined at compile-time (foo((A) object) or foo((B) object) result in foo_A being called or foo_B). So in a way this is compile-time polymorphism, although the real method (i.e. which implementation in the class hierarchy to take) is determined at runtime.

Enrol

Answer 5

I have strong objection to call method overloading as compile time polymorphism.
I agree that method overloading is static binding(compile time) but i didn't see polymorphism in that.

I tried to put my opinion in my question to get clarification. you can refer this link.

Ecclesiastical