skip to content

In Kotlin, why is the `override` keyword mandatory when redefining a member from a superclass or interface, and what happens if you omit it?

level: juniorimportance: must knowfreq 75%

answer

  1. Mandatory keyword, not an annotation
  2. Omit it → 'needs override modifier' error
  3. Wrong signature → 'overrides nothing' error
  4. Parent must be open/abstract first
  5. Catches typos Java would silently shadow

basics

~10 s

You must write override before a function or property that replaces one from the parent. It makes your intent explicit. If you forget it, the code does not compile.

solid answer

~40 s

Kotlin makes `override` mandatory to redefine an inherited member. Unlike Java's optional `@Override` annotation, in Kotlin it is a real keyword and the compiler enforces it. If you write a function with the same signature as a `open` (or abstract) parent member without `override`, you get a compile error: "'foo' hides member of supertype and needs the 'override' modifier". Conversely, if you add `override` but no matching open member exists in any supertype, you also get an error: "'foo' overrides nothing". This two-way checking prevents accidental shadowing and catches typos in signatures at compile time. It also documents intent: a reader sees `override` and knows the member comes from a supertype.

code

kotlin · 9 lines
kotlin
open class Greeter {
    open fun greet() = "Hello"
}

class Loud : Greeter() {
    override fun greet() = "HELLO"   // OK
    // fun greet() = "hi"            // ERROR: needs 'override'
    // override fun gret() = "hi"    // ERROR: overrides nothing
}

go deeper

for a junior

Knows you must write override and that forgetting it is a compile error.

for a middle

Explains the two-way check ('needs override' vs 'overrides nothing') and the link to open.

for a senior

Contrasts with Java's optional @Override, citing refactor-safety and silent-shadowing prevention.

for a principal

Frames it as a deliberate language design choice trading verbosity for compile-time correctness across evolving APIs.

## What `override` means When a subclass or implementing class redefines a member (function or property) that exists in a supertype, Kotlin requires the **`override` keyword** in front of that member. It is part of the language grammar — not an annotation like Java's optional `@Override`. ## Two compile-time rules The compiler enforces a strict two-way contract: - **You declare a member that matches an open/abstract supertype member but omit `override`** → error: *"... hides member of supertype ... and needs the 'override' modifier"*. This stops you from *accidentally* shadowing a parent member. - **You write `override` but no matching member exists** in any supertype → error: *"'...' overrides nothing"*. This catches typos in the name or parameter types. ## Why it exists - **Intent is explicit.** A reader instantly knows the member came from a supertype. - **Refactor safety.** If a base class renames or removes a method, every overrider that still says `override` fails to compile, so you find all call sites immediately. - **No silent shadowing.** In Java, a typo in a parameter type silently creates a brand-new overloaded method instead of an override; `@Override` is needed to catch it but is optional. Kotlin removes the foot-gun by making the keyword mandatory. ## Relationship to `open` A parent member must itself be `open` (or `abstract`, or an interface member) before it can be overridden — classes and members are `final` by default in Kotlin. `override` only applies once the parent has opted in. ```kotlin open class Animal { open fun speak() = "..." } class Dog : Animal() { override fun speak() = "Woof" // 'override' required } ``` Note: an `override` member is itself implicitly `open` to further subclasses unless you mark it `final override`.

  • How does Kotlin's `override` differ from Java's `@Override`?
    Java's `@Override` is an optional annotation; Kotlin's `override` is a mandatory keyword enforced by the compiler, so missing or stray overrides are always compile errors.
  • Can you override a member that is not declared `open`?
    No. Members are final by default; the parent member must be `open`, `abstract`, or an interface member, otherwise the compiler rejects the override.

Like having to sign a form acknowledging you are replacing the previous version — no signature, the change is rejected.

saying these in an interview costs you the question

  • Saying `override` is optional or just documentation
  • Confusing it with the `@Override` annotation from Java
  • Thinking any method can be overridden without `open`
  • Believing a missing `override` silently shadows the parent at runtime

context

resolving links…