{"title":"super Keyword","description":"","content":"The `extends` lesson showed that a child class inherits the parent's fields and methods automatically. Most of the time inheritance is invisible: the child uses inherited members as if it had written them itself. But sometimes the child needs to reach into the parent on purpose, to read a field that the child has hidden with a same-named field, to call the parent's version of a method that the child has replaced, or to hand arguments to a specific parent constructor. `super` is the keyword that does all three.\n\n---\n\n# The Three Jobs of `super`\n\n`super` is a reference to the parent half of the current object. From inside a child class, you can put `super.` in front of a name to pin the lookup to the parent's version. There are only three places it shows up in practice, and they map to the three jobs.\n\n\n| Form | Where it appears | What it does |\n| --- | --- | --- |\n| `super.field` | Inside an instance method or constructor | Reads or writes the parent's field with that name |\n| `super.method(...)` | Inside an instance method | Calls the parent's version of a method, ignoring any override in the child |\n| `super(...)` | First statement of a child constructor | Calls a specific parent constructor before the child runs |\n\n\nEvery example in this lesson is one of those three forms. They look similar (all use the keyword `super`), but they do different jobs and follow different rules. The simplest mental model is \"the parent half of me\". When you write `super.something`, you're asking for the version of `something` that belongs to the parent layer of this object, not the version the child redefined.\n\nA child object is a single object that has both layers inside it. The parent fields live in the same object as the child fields, and the parent methods are still there in the method table. `super` is just a name for \"look at the parent layer when resolving this\".\n\n\n```mermaid\nflowchart TD\n Object[\"Book object
(single instance on the heap)\"]:::cyan\n Object --> ParentLayer[\"Parent layer:
name, price
describe() from Product\"]:::orange\n Object --> ChildLayer[\"Child layer:
author, isbn
describe() from Book\"]:::green\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe diagram is conceptual, not how the JVM lays bytes out in memory. One object holds both layers. `this` looks at the child layer first and falls through to the parent. `super` skips the child and goes straight to the parent layer.\n\nBefore going further, three small facts to pin down:\n\n- `super` isn't an object reference you can assign to a variable. It's a keyword the compiler recognizes only in specific positions.\n- `super` only exists inside non-static instance code (instance methods and constructors). There's no `super` in a static method, just as there's no `this` in a static method.\n- `super` only goes up one level. You can write `super.method()`, but you can't write `super.super.method()`. Java doesn't have a syntax for \"skip two parents up\".\n\n---\n\n# Accessing a Shadowed Field with `super.field`\n\nField shadowing happens when a child class declares a field with the same name as a field in its parent. Both fields exist on the object. The child's field hides the parent's field whenever the child code refers to that name without qualification.\n\nHere's the smallest example that shows the trap.\n\n\n```java\nclass Product {\n String name = \"Generic Product\";\n}\n\nclass Book extends Product {\n String name = \"Untitled Book\";\n\n public void show() {\n System.out.println(\"Bare name: \" + name);\n System.out.println(\"this.name: \" + this.name);\n System.out.println(\"super.name: \" + super.name);\n }\n\n public static void main(String[] args) {\n new Book().show();\n }\n}\n```\n\n\nBoth fields exist on the same `Book` object. Inside `Book`, a bare `name` and `this.name` both resolve to the child's field, because the lookup starts at the child and stops as soon as it finds a match. `super.name` is the only way to reach the parent's field that the child has shadowed.\n\nIn real code, this is almost always a mistake. If a child class redeclares a field that the parent already has, you end up with two storage slots that mean the same thing, and code in the parent and child sees different values. The parent's methods still read the parent's field, while child methods read the child's field. Output gets confusing fast.\n\nThe cost here's not performance, it's confusion. Field shadowing is legal Java but almost always a code smell. If you find yourself needing `super.field` to undo a shadow you created on purpose, step back and ask whether the child should reuse the parent's field instead.\n\nThe pattern shows up legitimately when a child class wants to keep its own version of a value while still being able to read what the parent stored. A real e-commerce example: a `PhysicalProduct` that has its own display price (already including shipping) but still wants to know the parent's base price.\n\n\n```java\nclass Product {\n String name;\n double price;\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n\nclass PhysicalProduct extends Product {\n double price;\n\n public PhysicalProduct(String name, double basePrice, double shipping) {\n super(name, basePrice);\n this.price = basePrice + shipping;\n }\n\n public void describe() {\n System.out.println(name + \" base: $\" + super.price);\n System.out.println(name + \" with shipping: $\" + this.price);\n }\n\n public static void main(String[] args) {\n PhysicalProduct desk = new PhysicalProduct(\"Standing Desk\", 199.0, 25.0);\n desk.describe();\n }\n}\n```\n\n\nThe `PhysicalProduct` declares its own `price` field that includes shipping. The parent's `price` still holds the base. `super.price` reads the parent's field, `this.price` reads the child's. Both live inside the same object. This is the rare case where intentional shadowing is acceptable, but it's also exactly the kind of code that confuses readers, so most teams would rename one of the two fields (`displayPrice`, `totalPrice`, or `basePrice`) instead.\n\n---\n\n# Calling a Parent Method with `super.method()`\n\nThe second job of `super` is calling the parent's version of a method that the child has overridden. This is the most common use of `super` in production code, because overriding is the whole point of inheritance for behavior.\n\nOverriding will get its full lesson next; for now you only need the rough idea. When a child class defines a method with the same signature as a parent method, the child's version replaces the parent's version for any call on a `Book` object. That replacement is permanent, except for one escape hatch: from inside the overriding method, the child can still call the parent's version with `super.method()`.\n\nHere's the e-commerce example the rest of the lesson will keep coming back to.\n\n\n```java\nclass Product {\n String name;\n double price;\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n public String describe() {\n return name + \" - $\" + price;\n }\n}\n\nclass Book extends Product {\n String author;\n\n public Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n\n @Override\n public String describe() {\n return super.describe() + \" by \" + author;\n }\n\n public static void main(String[] args) {\n Book book = new Book(\"Effective Java\", 49.99, \"Joshua Bloch\");\n System.out.println(book.describe());\n }\n}\n```\n\n\nThe `Book` class wants its `describe` to extend the parent's description, not replace it. A naive override would have to duplicate the `name + \" - $\" + price` part. Instead, the child calls `super.describe()` to get whatever the parent produces, then adds its own piece on top. If the parent later changes how it formats the description (say, adds a currency symbol), the child automatically picks up the change because it never hard-coded the parent's format.\n\nThe flow looks like this when you call `book.describe()`:\n\n\n```mermaid\nflowchart LR\n Caller[\"book.describe()\"]:::cyan --> ChildMethod[\"Book.describe():
String s = super.describe()\"]:::orange\n ChildMethod --> ParentMethod[\"Product.describe():
return name + - $ + price\"]:::green\n ParentMethod --> BackToChild[\"control returns to Book.describe()\"]:::orange\n BackToChild --> Final[\"return s + by + author\"]:::teal\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe child method runs first because the call lands on a `Book`. From inside that body, `super.describe()` hops up one level and runs the parent's method. When that returns, control comes back to the child, which appends its own piece and returns the final string.\n\nA few details:\n\n- The `super.describe()` call inside `Book.describe()` is the only thing keeping this from being an infinite loop. A bare `describe()` (or `this.describe()`) inside the child would call the child's own method again and recurse forever.\n- The parent method still sees the same object. When `super.describe()` runs `name + \" - $\" + price`, those fields belong to the `Book` instance, not to some separate `Product`. The keyword `super` only changes which version of the method runs, not which object the fields belong to.\n- The `@Override` annotation here's a safety net. It tells the compiler \"I intend this to override a parent method\". If you misspell the method name or change the signature, the compiler catches it.\n\nWhat about calling `super.method()` outside an override? It works, but it's almost never what you want.\n\n\n```java\nclass Book extends Product {\n public void debugParent() {\n System.out.println(super.describe());\n }\n}\n```\n\n\nInside `debugParent`, calling `super.describe()` is identical to calling `this.describe()` for a `Book` that doesn't override `describe`. Once the child does override, `super.describe()` becomes the explicit way to reach past the override. So the pattern is almost always: \"I am overriding a method, and I want to reuse the parent's version inside my own.\"\n\n---\n\n# Calling a Parent Constructor with `super(...)`\n\nThe third job is `super(...)`, with parentheses. Inside a constructor, `super(...)` calls a specific constructor of the parent class. It's the only way to pass arguments to the parent during object construction.\n\nLook back at the `Book` example. Its constructor took three arguments, but `Product` doesn't know about `author`. `Product` only knows how to set `name` and `price`. So the `Book` constructor delegates the parent's fields to the parent's constructor and then handles `author` itself.\n\n\n```java\npublic Book(String name, double price, String author) {\n super(name, price); // run Product(String, double) first\n this.author = author; // then do Book-specific work\n}\n```\n\n\nWhat happens at runtime, in order:\n\n1. You write `new Book(\"Effective Java\", 49.99, \"Joshua Bloch\")`.\n2. The JVM allocates memory for a `Book` object with all fields at their defaults (`null`, `0.0`, etc.).\n3. The `Book` constructor body starts running, and its first statement is `super(name, price)`.\n4. The `Product(String, double)` constructor runs, setting `this.name` and `this.price` on the same object.\n5. Control returns to the `Book` constructor.\n6. The `Book` constructor finishes its own work: `this.author = author`.\n7. The `new` expression returns the fully built `Book`.\n\n\n```mermaid\nflowchart TD\n NewCall[\"new Book(name, price, author)\"]:::cyan --> BookCtor[\"Book constructor starts
super(name, price)\"]:::orange\n BookCtor --> ProductCtor[\"Product constructor runs
this.name = name
this.price = price\"]:::green\n ProductCtor --> BackToBook[\"control returns to Book constructor\"]:::orange\n BackToBook --> BookRest[\"this.author = author\"]:::teal\n BookRest --> Done[\"Book object ready\"]:::cyan\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe parent half of the object is built before the child half. That makes sense: if the child constructor wants to use any parent fields, those fields need to be in place first.\n\nA few rules you need to know now:\n\n- `super(...)` must be the **first statement** of a constructor when it appears. Nothing else can run before it.\n- A constructor can have **at most one** explicit constructor call at the top, either `super(...)` or `this(...)`, never both.\n- If you don't write a `super(...)` call, Java inserts an implicit `super()` (the no-argument parent constructor) for you. This is why simple constructors work even when they never mention `super`.\n\nThe implicit `super()` rule has one common gotcha: if the parent doesn't have a no-argument constructor, you must write `super(...)` explicitly. Trying to compile the code below fails:\n\n**What's wrong with this code?**\n\n\n```java\nclass Product {\n String name;\n double price;\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n\nclass GiftCard extends Product {\n double balance;\n\n public GiftCard(double balance) {\n this.balance = balance;\n }\n}\n```\n\n\n**Fix:**\n\n\n```java\nclass GiftCard extends Product {\n double balance;\n\n public GiftCard(double balance) {\n super(\"Gift Card\", balance);\n this.balance = balance;\n }\n}\n```\n\n\nThe broken version compiles to an implicit `super()` at the top of `GiftCard`'s constructor, but `Product` has no `Product()` constructor. The compiler reports `constructor Product in class Product cannot be applied to given types`. Adding an explicit `super(\"Gift Card\", balance)` tells the compiler which parent constructor to use.\n\nOne variation. If you want each `GiftCard` to share a single \"Gift Card\" name without writing it into the constructor every time, you can hard-code it:\n\n\n```java\npublic GiftCard(double balance) {\n super(\"Gift Card\", balance); // every gift card is named \"Gift Card\"\n this.balance = balance;\n}\n```\n\n\nThe full mechanics of constructor chaining (implicit calls, `this()` vs `super()`, who runs first across multi-level hierarchies) is its own lesson next. For this lesson, what matters is: `super(...)` is how a child constructor passes data to a parent constructor.\n\n---\n\n# `super` vs `this`\n\nThe two keywords look symmetric, and a lot of the rules carry over. The side-by-side table below pins down the differences so you can refer back to it when something feels ambiguous.\n\n\n| Concept | `this` | `super` |\n| --- | --- | --- |\n| What it refers to | The current instance (whole object) | The parent layer of the current instance |\n| Field access | `this.field` reads/writes the field on the current object, child layer first | `super.field` reads/writes the field in the parent layer (skips child shadow) |\n| Method call | `this.method()` runs the method using normal dispatch (override-aware) | `super.method()` runs the parent's version, ignoring any override in the child |\n| Constructor call | `this(...)` calls another constructor of the same class | `super(...)` calls a constructor of the parent class |\n| Position in constructor | `this(...)` must be the first statement | `super(...)` must be the first statement |\n| Both at once? | No. A constructor can start with at most one of `this(...)` or `super(...)` | Same |\n| Inside a static method | Not allowed | Not allowed |\n| Can be reassigned | No, it's a keyword, not a variable | No, same |\n\n\nA quick way to keep them straight:\n\n- `this` answers \"which object am I?\". `super` answers \"what does the parent layer say?\".\n- `this.field` and `this.method()` are about a possibly-shadowed or overridden lookup that walks the class hierarchy and picks the most specific version. `super.field` and `super.method()` skip the child and start at the parent.\n- `this(...)` and `super(...)` are constructor delegation. One stays in the same class; the other goes up one level.\n\nThe shared rule that catches beginners: any explicit constructor call must be the first statement. That applies whether it's `this(...)` or `super(...)`. You can never have both.\n\n\n```java\npublic Book(String name, double price, String author) {\n super(name, price); // legal: super first\n this.author = author; // legal: regular field assignment\n}\n\npublic Book(String name, double price, String author) {\n this(name, price, author, \"Uncategorized\"); // legal: this first\n}\n\npublic Book(String name, double price, String author) {\n super(name, price);\n this(name, price, author, \"Uncategorized\"); // illegal: cannot have both\n}\n```\n\n\nThe third version doesn't compile. Pick one constructor call at the top, then write the rest of the body.\n\n---\n\n# Common Patterns: Extending Behavior in an Override\n\nThe most useful pattern in real code is \"do what the parent does, then add my piece\". The `Book.describe` example earlier did exactly this. The pattern shows up so often that it has a name in some style guides: \"calling super\". It's a way of extending behavior instead of replacing it.\n\nA slightly larger example with three product types. The parent does the shared work, and each child adds its own information on top.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\nclass Product {\n String name;\n double price;\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n public String describe() {\n return name + \" - $\" + price;\n }\n}\n\nclass Book extends Product {\n String author;\n\n public Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n\n @Override\n public String describe() {\n return super.describe() + \" by \" + author;\n }\n}\n\nclass Electronics extends Product {\n int warrantyMonths;\n\n public Electronics(String name, double price, int warrantyMonths) {\n super(name, price);\n this.warrantyMonths = warrantyMonths;\n }\n\n @Override\n public String describe() {\n return super.describe() + \" (warranty: \" + warrantyMonths + \" months)\";\n }\n}\n\nclass GiftCard extends Product {\n String code;\n\n public GiftCard(double price, String code) {\n super(\"Gift Card\", price);\n this.code = code;\n }\n\n @Override\n public String describe() {\n return super.describe() + \" [code \" + code + \"]\";\n }\n\n public static void main(String[] args) {\n List catalog = new ArrayList<>();\n catalog.add(new Book(\"Effective Java\", 49.99, \"Joshua Bloch\"));\n catalog.add(new Electronics(\"Wireless Mouse\", 29.99, 12));\n catalog.add(new GiftCard(50.0, \"AM-2026\"));\n\n for (Product item : catalog) {\n System.out.println(item.describe());\n }\n }\n}\n```\n\n\nThree children, three overrides, all using the same trick: each child calls `super.describe()` to get the formatted name and price, then appends its own piece. If `Product.describe` ever changes (say, to put the price first), every child picks up the change without any edits. Without the `super` call, every child would duplicate the formatting logic, and a future change would mean editing three places instead of one.\n\nA second common variation: the child wraps the parent's call in extra logic, like logging or validation.\n\n\n```java\nclass Product {\n int stock;\n\n public Product(int stock) {\n this.stock = stock;\n }\n\n public void reduceStock(int amount) {\n stock -= amount;\n }\n}\n\nclass DigitalProduct extends Product {\n public DigitalProduct(int stock) {\n super(stock);\n }\n\n @Override\n public void reduceStock(int amount) {\n System.out.println(\"Logging: digital download requested, amount = \" + amount);\n super.reduceStock(amount);\n System.out.println(\"Logging: stock after = \" + stock);\n }\n\n public static void main(String[] args) {\n DigitalProduct download = new DigitalProduct(100);\n download.reduceStock(3);\n }\n}\n```\n\n\nThe child adds before-and-after logging without replacing what the parent does. `super.reduceStock(amount)` keeps the actual decrement in one place (the parent). The child just decorates around it.\n\nThere's a discipline question hidden here. Some methods are designed to be extended this way; others are designed to be replaced wholesale. The parent class can document the expectation, or in advanced cases use the template method pattern. For now, the rule of thumb: if your override could reuse the parent's work, call `super.method()` first and then add. Don't reinvent the parent's behavior in the child.\n\n---\n\n# Limits and Pitfalls\n\n`super` looks simple, and most uses are. A few standard pitfalls come up often enough to be worth calling out.\n\n### You Can't Use `super` in a `static` Context\n\nStatic methods belong to the class, not to any particular object. There's no current instance, which means there's no \"parent of the current instance\" either. Trying to use `super` in a static method fails to compile.\n\n**What's wrong with this code?**\n\n\n```java\nclass Product {\n public static String greeting() {\n return \"Welcome\";\n }\n}\n\nclass Book extends Product {\n public static String greeting() {\n return super.greeting() + \" to Books\"; // compile error\n }\n}\n```\n\n\n**Fix:**\n\n\n```java\nclass Book extends Product {\n public static String greeting() {\n return Product.greeting() + \" to Books\";\n }\n}\n```\n\n\nThe compiler error reads `non-static variable super cannot be referenced from a static context`. Static methods aren't overridden in the same way instance methods are (they're hidden, not overridden), so the way to call a parent's static method is by its class name, not by `super`.\n\n### You Can't Skip Levels with `super.super.method()`\n\n`super` always means \"exactly one level up\". There's no `super.super` syntax to reach the grandparent.\n\n**What's wrong with this code?**\n\n\n```java\nclass Product {\n public String describe() { return \"Product\"; }\n}\n\nclass Electronics extends Product {\n @Override\n public String describe() { return \"Electronics\"; }\n}\n\nclass Phone extends Electronics {\n @Override\n public String describe() {\n return super.super.describe(); // compile error\n }\n}\n```\n\n\n**Fix:**\n\nThere's no language-level fix. Java intentionally doesn't let you skip levels in the hierarchy. The fix is to redesign so the child doesn't need to reach past its immediate parent. The most common approach is to have the parent expose what the child needs:\n\n\n```java\nclass Electronics extends Product {\n @Override\n public String describe() { return \"Electronics\"; }\n\n public String parentDescribe() {\n return super.describe(); // Electronics can call up to Product\n }\n}\n\nclass Phone extends Electronics {\n @Override\n public String describe() {\n return parentDescribe();\n }\n}\n```\n\n\n`Electronics` can reach `Product` (one level up), and `Phone` can reach the helper that `Electronics` exposes. Each `super` call is one step. If your design wants the grandchild to ignore its parent entirely, the usual fix is to flatten the hierarchy.\n\n### `super(...)` Must Be First\n\nThe compiler enforces this strictly. You can't print, validate, log, or assign anything before `super(...)`.\n\n\n```java\npublic Book(String name, double price, String author) {\n System.out.println(\"Building book\"); // compile error: super call no longer first\n super(name, price);\n this.author = author;\n}\n```\n\n\nThe fix is to move `super(...)` to the first line. If you want to compute an argument first, you've to do it inline:\n\n\n```java\npublic Book(String name, double price, String author) {\n super(name.toUpperCase(), price); // inline computation is fine\n this.author = author;\n}\n```\n\n\nJava 22 added a preview feature called \"Flexible Constructor Bodies\" (statements before `super(...)`) that relaxes this in narrow cases, and it became a standard feature in Java 25. For the long-stable behavior most projects target today, treat the strict first-statement rule as absolute.\n\n### Implicit `super()` with No Matching Parent Constructor\n\nThis is the most common compile error involving `super`. If you write a constructor that doesn't start with `this(...)` or `super(...)`, the compiler inserts an implicit `super()`. That implicit call requires the parent to have a no-arg constructor.\n\n\n```java\nclass Product {\n public Product(String name, double price) {\n // no-arg constructor missing\n }\n}\n\nclass Book extends Product {\n public Book() {\n // implicit super() here, but Product() doesn't exist\n }\n}\n```\n\n\nThe compiler error reads `constructor Product in class Product cannot be applied to given types; required: String,double; found: no arguments`. The fix is either to add `super(\"Default\", 0.0)` (or some sensible parent arguments) to `Book`, or to add a `Product()` no-arg constructor to the parent.\n\n### Forgetting `super(...)` When You Need It\n\nA child constructor can do its own work without ever mentioning the parent's fields, and the parent fields still get default values from the implicit `super()`. That can hide a bug where the child meant to pass real data up but forgot.\n\n\n```java\nclass Product {\n String name = \"Unknown\";\n double price = 0.0;\n\n public Product() {}\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n\nclass Book extends Product {\n String author;\n\n public Book(String name, double price, String author) {\n // forgot super(name, price); fields stay \"Unknown\" and 0.0\n this.author = author;\n }\n\n public static void main(String[] args) {\n Book b = new Book(\"Effective Java\", 49.99, \"Joshua Bloch\");\n System.out.println(b.name + \" \" + b.price + \" \" + b.author);\n }\n}\n```\n\n\nThe implicit `super()` runs the no-arg `Product()`, which leaves the fields at their declared defaults. Nothing is technically wrong, the program compiles and runs, but the data is wrong. The fix is to call `super(name, price)` explicitly. Make a habit of checking the first line of every constructor in a child class: it should be a `super(...)` call with real arguments unless the parent has nothing to initialize.","pageType":"java"}

super Keyword

Get Premium