Compile-time vs Runtime Polymorphism

## Setting the stage: what is polymorphism? **Polymorphism** (Greek: "many forms") means a single name or interface can refer to different concrete behaviors. In Java this shows up in two distinct mechanisms that beginners often confuse: **overloading** and **overriding**. They look superficially similar (two methods with the same name) but they are resolved at completely different times and for completely different reasons. ### Key term: method signature A method's **signature** is its name plus the ordered list of its parameter types. For example `area(int)` and `area(int, int)` and `area(double)` are three different signatures. **The return type is NOT part of the signature.** This single fact explains many of the rules below. ### Key term: static (declared) type vs dynamic (runtime) type When you write `Animal a = new Dog();`, the variable `a` has: - a **static type** (also called declared or compile-time type) of `Animal` — what the compiler sees from the declaration, and - a **dynamic type** (runtime type) of `Dog` — the actual class of the object that exists in memory at runtime. The whole overloading-vs-overriding distinction comes down to *which of these two types is used to choose the method*. ## Method overloading = compile-time (static) polymorphism **Overloading** means defining several methods with the **same name but different signatures** (different parameter count, types, or order). They are independent methods that merely share a name for readability. ```java int add(int a, int b) { return a + b; } double add(double a, double b) { return a + b; } int add(int a, int b, int c) { return a + b + c; } ``` When you call `add(2, 3)`, the **compiler** looks at the *static types* of the arguments (`int`, `int`) and picks the matching overload **at compile time**. The chosen method is effectively baked into the bytecode. Because the decision is made before the program ever runs, this is called **compile-time**, **static**, or **early binding** polymorphism. Rules and gotchas: - Overloads must differ in their parameter list. **You cannot overload by return type alone** — `int f()` and `double f()` would be ambiguous because nothing at the call site tells the compiler which to pick. - Java applies a resolution order: it first tries an exact match, then **widening** (e.g. `int`→`long`→`double`), then **autoboxing** (`int`→`Integer`), then **varargs**. This can produce surprising choices. - Overloading can happen in one class or across a parent/child class. ## Method overriding = runtime (dynamic) polymorphism **Overriding** means a subclass supplies its own body for an inherited method using the **exact same signature**. ```java class Animal { String sound() { return "..."; } } class Dog extends Animal { @Override String sound() { return "Woof"; } } class Cat extends Animal { @Override String sound() { return "Meow"; } } Animal a = new Dog(); a.sound(); // "Woof" ``` Here the compiler only knows `a` is an `Animal`, so it cannot decide which `sound()` to run. The decision is deferred to **runtime**, where the JVM inspects the *dynamic type* of the object (`Dog`) and dispatches to `Dog.sound()`. This is called **runtime**, **dynamic**, or **late binding** polymorphism, and the mechanism that performs it is **dynamic method dispatch** (covered in its own question). Rules and gotchas: - The signature must match exactly; if it differs you have accidentally *overloaded*, not overridden — this is why the `@Override` annotation exists: it makes the compiler verify you really are overriding. - The access modifier cannot be more restrictive than the parent's. - The return type must be the same or a **covariant** (subtype) return. - `static`, `private`, and `final` methods cannot be overridden (statics are *hidden*, not overridden — they bind statically). - Fields are never overridden; field access is always resolved by static type (this is *field hiding*). ## Side-by-side summary | | Overloading | Overriding | |---|---|---| | Signature | must DIFFER | must be IDENTICAL | | Resolved using | static type of arguments | dynamic type of object | | Resolved when | compile time | runtime | | Other names | static / early binding | dynamic / late binding | | Across classes? | same class or hierarchy | strictly parent → child | ## Deriving the answer At any level you can reconstruct the right answer from one principle: **overloading varies the signature and is chosen by the compiler from declared types; overriding keeps the signature and is chosen by the JVM from the real object.** Everything else (return-type rule, `@Override`, covariance, statics) follows from that.