{"title":"Constructor Chaining","description":"","content":"Constructors are not inherited the way fields and methods are. Every subclass writes its own constructors. But every constructor in a subclass eventually runs one in its parent, which runs one in its parent, all the way up to `java.lang.Object`. That guaranteed walk up the hierarchy is called constructor chaining, and this lesson covers how it works, the two keywords that drive it (`this(...)` and `super(...)`), and the rules and pitfalls that come with it.\n\n---\n\n# Why Chaining Exists\n\nA subclass object physically contains every field declared by its parent. A `Book` that extends `PhysicalProduct` which extends `Product` has the `name` and `price` fields from `Product`, the `weight` field from `PhysicalProduct`, and the `author` field from `Book`, all packed into one object. Those parent fields have to be initialized before any subclass code uses them.\n\nConstructor chaining is Java's mechanism for guaranteeing that. Before a child constructor's body runs, the parent constructor must have already finished. By the time you write `this.author = author` in the `Book` constructor, you can rely on `name`, `price`, and `weight` already holding their proper values.\n\nA small hierarchy makes the point concrete:\n\n\n```java\npublic class 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\npublic class PhysicalProduct extends Product {\n double weightKg;\n\n public PhysicalProduct(String name, double price, double weightKg) {\n super(name, price);\n this.weightKg = weightKg;\n }\n}\n\npublic class Book extends PhysicalProduct {\n String author;\n\n public Book(String name, double price, double weightKg, String author) {\n super(name, price, weightKg);\n this.author = author;\n }\n\n public static void main(String[] args) {\n Book b = new Book(\"Effective Java\", 39.99, 0.7, \"Joshua Bloch\");\n System.out.println(b.name + \" by \" + b.author);\n System.out.println(\"Price: $\" + b.price + \", weight: \" + b.weightKg + \" kg\");\n }\n}\n```\n\n\nThe `Book` constructor sets `author`, but the other three fields come from somewhere. They come from the parent constructors running first. Without that, `Book` would have to reach up into the parent and set those fields itself, which is messy and breaks encapsulation. Chaining keeps each class responsible for its own initialization.\n\nThe rule that drives this: **parent state must be fully initialized before any child code touches it.** Every other piece of constructor-chaining behavior is a consequence of enforcing that one invariant.\n\n---\n\n# The Full Chain to `Object`\n\nEvery class in Java extends some other class, either explicitly with `extends` or implicitly. A class declared as `public class Product { ... }` extends `java.lang.Object`. That makes `Object` the silent root of every hierarchy. When you construct a `Book`, the chain runs all the way up.\n\nThe sequence of constructor calls when `new Book(\"Effective Java\", 39.99, 0.7, \"Joshua Bloch\")` runs:\n\n\n```mermaid\nsequenceDiagram\n participant Caller\n participant Book\n participant PhysicalProduct\n participant Product\n participant Object\n\n Caller->>Book: new Book(name, price, weight, author)\n Book->>PhysicalProduct: super(name, price, weight)\n PhysicalProduct->>Product: super(name, price)\n Product->>Object: super() implicit\n Object-->>Product: Object body done\n Product-->>PhysicalProduct: Product body done (name, price set)\n PhysicalProduct-->>Book: PhysicalProduct body done (weight set)\n Book-->>Caller: Book body done (author set), reference returned\n```\n\n\nRead the diagram top to bottom: each constructor's first action is to invoke its parent's constructor. Once Java reaches `Object`, the chain unwinds. `Object`'s constructor finishes first, then `Product`'s body runs, then `PhysicalProduct`'s, then `Book`'s. The caller receives the reference only after every body in the chain has completed.\n\nTwo consequences fall out of this picture:\n\n- The deepest class's constructor body runs **last**, not first.\n- If anything throws an exception partway up the chain, the object is never returned. The caller sees the exception, not a half-built object.\n\nThis is the chain. Everything else in the lesson is about how Java decides exactly which parent constructor to call at each step.\n\n---\n\n# `this(...)`: Calling Another Constructor in the Same Class\n\n`this(...)` calls another constructor in the **same class**. It's a way to remove duplication when several constructors set up the same fields with different defaults. A short example, since it pairs naturally with `super(...)`:\n\n\n```java\npublic class Product {\n String name;\n double price;\n int stock;\n String category;\n\n public Product(String name, double price, int stock, String category) {\n this.name = name;\n this.price = price;\n this.stock = stock;\n this.category = category;\n }\n\n public Product(String name, double price) {\n this(name, price, 0, \"Uncategorized\");\n }\n\n public Product(String name) {\n this(name, 0.0);\n }\n\n public static void main(String[] args) {\n Product full = new Product(\"Wireless Mouse\", 29.99, 50, \"Electronics\");\n Product mid = new Product(\"USB Cable\", 9.99);\n Product bare = new Product(\"Unnamed\");\n\n System.out.println(full.name + \" / $\" + full.price + \" / \" + full.stock + \" / \" + full.category);\n System.out.println(mid.name + \" / $\" + mid.price + \" / \" + mid.stock + \" / \" + mid.category);\n System.out.println(bare.name + \" / $\" + bare.price + \" / \" + bare.stock + \" / \" + bare.category);\n }\n}\n```\n\n\nThe two short constructors delegate to the four-argument one through `this(...)`. The full constructor is the only place that touches the fields directly. If you add a new field, you change the long constructor and every short constructor automatically picks up the new behavior.\n\nA constructor calling `this(...)` runs **before** its own body. So in the two-argument constructor, the call `this(name, price, 0, \"Uncategorized\")` runs the four-argument constructor first, and only after that returns does any other code in the two-argument body run (there's none here, but there could be).\n\n`this(...)` chains within one class. `super(...)` chains across the parent boundary. A single constructor can use one or the other, never both.\n\n---\n\n# `super(...)`: Calling a Parent Constructor\n\n`super(...)` is the keyword that walks the chain upward. From any subclass constructor, `super(args)` calls a matching constructor in the immediate parent class. The parent then chains to its own parent, and so on up to `Object`.\n\nThe mechanics:\n\n- `super(...)` must appear in the **first line** of a subclass constructor body.\n- The argument list of `super(...)` is matched against the parent's constructors using the same overload resolution rules as a regular method call (exact, widening, autoboxing, varargs).\n- If no parent constructor matches the arguments, the code fails to compile.\n\nThe e-commerce hierarchy again, this time annotated with print statements so you can watch the chain run:\n\n\n```java\npublic class Product {\n String name;\n double price;\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n System.out.println(\"Product constructor done: \" + name);\n }\n}\n\npublic class PhysicalProduct extends Product {\n double weightKg;\n\n public PhysicalProduct(String name, double price, double weightKg) {\n super(name, price);\n this.weightKg = weightKg;\n System.out.println(\"PhysicalProduct constructor done: \" + weightKg + \" kg\");\n }\n}\n\npublic class Book extends PhysicalProduct {\n String author;\n\n public Book(String name, double price, double weightKg, String author) {\n super(name, price, weightKg);\n this.author = author;\n System.out.println(\"Book constructor done: \" + author);\n }\n\n public static void main(String[] args) {\n new Book(\"Effective Java\", 39.99, 0.7, \"Joshua Bloch\");\n }\n}\n```\n\n\nThe order is significant. The `Book` constructor was the one we called, but its print statement runs last. The first thing the `Book` constructor body does is `super(...)`, which makes Java jump up to `PhysicalProduct`. That in turn jumps up to `Product`. `Product`'s body runs (and prints) first because it's the deepest constructor reached before the chain starts unwinding. Then control returns down through `PhysicalProduct` and finally to `Book`.\n\n`super(...)` is not the same as `super.someMethod()`. Here we only use the constructor form.\n\n---\n\n# The First-Statement Rule\n\nIf you write `this(...)` or `super(...)`, it must be the **first statement** in the constructor body. Not the first non-comment line. The first actual statement. Anything before it is a compile error.\n\n\n```java\npublic class PhysicalProduct extends Product {\n double weightKg;\n\n public PhysicalProduct(String name, double price, double weightKg) {\n if (weightKg < 0) {\n throw new IllegalArgumentException(\"weight must be non-negative\");\n }\n super(name, price); // ERROR\n this.weightKg = weightKg;\n }\n}\n```\n\n\nThe compiler refuses this with:\n\n\n```shell\nerror: call to super must be first statement in constructor\n super(name, price);\n ^\n```\n\n\nThe rule has a purpose. Java needs to guarantee that the parent's state is fully built before any subclass code runs, including validation. If you could sneak code in before `super(...)`, that code might call methods on the partially-built object, and the parent's fields wouldn't yet hold their proper values.\n\nTwo more rules go with the first-statement requirement:\n\n\n| Rule | What it means |\n| --- | --- |\n| Exactly one of `this(...)` or `super(...)` per constructor | You can use one or the other, never both. |\n| Either is optional | If you write neither, the compiler inserts an implicit `super()`. |\n| Must be the first statement | No code, no validation, no logging before it. |\n\n\nIf you legitimately need to validate inputs before passing them to `super(...)`, you have a few options. You can validate in the call itself by using a static helper:\n\n\n```java\npublic class PhysicalProduct extends Product {\n double weightKg;\n\n public PhysicalProduct(String name, double price, double weightKg) {\n super(name, price);\n if (weightKg < 0) {\n throw new IllegalArgumentException(\"weight must be non-negative\");\n }\n this.weightKg = weightKg;\n }\n\n private static double requireNonNegative(double value) {\n if (value < 0) {\n throw new IllegalArgumentException(\"must be non-negative\");\n }\n return value;\n }\n}\n```\n\n\nValidate after the `super(...)` call (as above), or wrap the argument in a static helper that throws before returning. Both are common patterns. Java 25 made the \"Flexible Constructor Bodies\" feature standard, allowing statements before `super(...)` in narrow cases, but for the long-stable language and any current production target, treat the first-statement rule as absolute.\n\nA `super(...)` or `this(...)` call is no more expensive than a regular method call. The first-statement rule is a language rule, not a performance one.\n\nA reasonable question to ask: can `super(...)` appear inside an `if` or a `try` block? No. \"First statement\" means literally the first statement at the top level of the constructor body. Putting it inside a conditional or a try block fails to compile with the same error message.\n\n---\n\n# The Implicit `super()` Call and When It Fails\n\nIf you don't write `this(...)` or `super(...)` as your first statement, the compiler inserts a hidden `super()` (no arguments) for you. This is why this class compiles even though it never mentions `super`:\n\n\n```java\npublic class Product {\n String name;\n double price;\n\n public Product() {\n this.name = \"Unknown\";\n this.price = 0.0;\n }\n}\n\npublic class PhysicalProduct extends Product {\n double weightKg;\n\n public PhysicalProduct(double weightKg) {\n // No super(...) call here.\n // Compiler inserts super(); on this line.\n this.weightKg = weightKg;\n }\n}\n```\n\n\nThe compiler sees that `PhysicalProduct(double)` doesn't call `super(...)` or `this(...)` explicitly, so it adds `super();`. That call resolves to `Product()`, the no-arg constructor, which exists and is accessible. The chain works.\n\nNow break it by removing the no-arg `Product` constructor:\n\n\n```java\npublic class 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\npublic class PhysicalProduct extends Product {\n double weightKg;\n\n public PhysicalProduct(double weightKg) {\n this.weightKg = weightKg;\n }\n}\n```\n\n\nThe `PhysicalProduct(double)` constructor still gets an implicit `super()` inserted, but `Product` no longer has a no-arg constructor. The compile error:\n\n\n```shell\nerror: constructor Product in class Product cannot be applied to given types;\n public PhysicalProduct(double weightKg) {\n ^\n required: String,double\n found: no arguments\n reason: actual and formal argument lists differ in length\n```\n\n\nThe error reads as if it's complaining about `PhysicalProduct`, but the real culprit is the implicit `super()` inside it. Java tried to call `Product()` and couldn't find one.\n\nThere are two clean fixes.\n\n**Fix 1: Add a no-arg constructor to the parent.**\n\n\n```java\npublic class Product {\n String name;\n double price;\n\n public Product() {\n this(\"Unknown\", 0.0);\n }\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n```\n\n\nNow `super()` resolves successfully and `PhysicalProduct(double)` compiles.\n\n**Fix 2: Call `super(...)` explicitly with arguments that match an existing parent constructor.**\n\n\n```java\npublic class PhysicalProduct extends Product {\n double weightKg;\n\n public PhysicalProduct(double weightKg) {\n super(\"Unknown\", 0.0);\n this.weightKg = weightKg;\n }\n}\n```\n\n\nThis call matches `Product(String, double)`. The implicit `super()` is no longer inserted because we wrote an explicit `super(...)` ourselves.\n\nWhich fix to pick? It depends on whether a no-arg `Product` is a meaningful concept in your code. If \"an unnamed, free product\" is a thing you'd ever want, add the no-arg constructor and let subclasses use it. If not, force every subclass to supply real values by only providing parameterized constructors, and accept that subclasses must call `super(...)` explicitly.\n\nA decision flowchart for \"will this constructor compile?\":\n\n\n```mermaid\nflowchart TD\n Start[Subclass constructor body]:::cyan --> Q1{First statement
is this... or super...?}\n Q1 -- this... --> R1[Compiles
chains within class]:::green\n Q1 -- super args --> Q2{Parent has matching
constructor?}\n Q2 -- Yes --> R2[Compiles
chains to parent]:::green\n Q2 -- No --> R3[Compile error
cannot be applied]:::red\n Q1 -- Neither --> Q3{Compiler inserts
implicit super}\n Q3:::orange --> Q4{Parent has
accessible no-arg
constructor?}\n Q4 -- Yes --> R4[Compiles
chains to parent]:::green\n Q4 -- No --> R5[Compile error
no default constructor]:::red\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 red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe decision tree captures the whole rule set. The implicit `super()` is invisible in your source, but it's still a constructor call, and it fails the same way any other call would if no matching constructor exists.\n\n---\n\n# Construction Order: Parent Fields, Parent Body, Child Fields, Child Body\n\nWhen `new` runs on a subclass, the work happens in a strict order. Each level of the hierarchy goes through a small four-phase sequence, but the levels themselves interleave because of how chaining works.\n\nThe precise order for `new Book(...)` against the `Product` -> `PhysicalProduct` -> `Book` chain:\n\n\n| Step | What happens |\n| --- | --- |\n| 1 | JVM allocates one block of memory big enough for all fields from `Object`, `Product`, `PhysicalProduct`, and `Book`. |\n| 2 | All fields are set to their default values (`0`, `false`, `null`). This applies to every field at every level at once. |\n| 3 | `Book(...)` is invoked; its first action is `super(...)`, which jumps up. |\n| 4 | `PhysicalProduct(...)` is invoked; its first action is `super(...)`, which jumps up. |\n| 5 | `Product(...)` is invoked; its first action is an implicit `super()` to `Object`. |\n| 6 | `Object`'s constructor body runs (empty for our purposes). |\n| 7 | Control returns to `Product(...)`. **`Product`'s field initializers run**, then `Product`'s body runs. |\n| 8 | Control returns to `PhysicalProduct(...)`. **`PhysicalProduct`'s field initializers run**, then its body runs. |\n| 9 | Control returns to `Book(...)`. **`Book`'s field initializers run**, then its body runs. |\n| 10 | The reference to the now-fully-built object is returned to the caller. |\n\n\n\"Field initializers\" are inline initializations like `private int stock = 0;` or `private List tags = new ArrayList<>();`. They count as part of the class's construction work, and they run before the class's constructor body but after that class's `super(...)` call returns. Initializer blocks (the `{ ... }` blocks inside a class body) run at the same point and in source order alongside the field initializers.\n\nA small program to watch this run:\n\n\n```java\npublic class Product {\n String name;\n int productCounter = recordInit(\"Product field initializer\");\n\n public Product(String name) {\n System.out.println(\"Product body starts\");\n this.name = name;\n System.out.println(\"Product body ends\");\n }\n\n static int recordInit(String label) {\n System.out.println(label);\n return 0;\n }\n}\n\npublic class PhysicalProduct extends Product {\n double weightKg;\n int physicalCounter = recordInit(\"PhysicalProduct field initializer\");\n\n public PhysicalProduct(String name, double weightKg) {\n super(name);\n System.out.println(\"PhysicalProduct body starts\");\n this.weightKg = weightKg;\n System.out.println(\"PhysicalProduct body ends\");\n }\n}\n\npublic class Book extends PhysicalProduct {\n String author;\n int bookCounter = recordInit(\"Book field initializer\");\n\n public Book(String name, double weightKg, String author) {\n super(name, weightKg);\n System.out.println(\"Book body starts\");\n this.author = author;\n System.out.println(\"Book body ends\");\n }\n\n public static void main(String[] args) {\n new Book(\"Effective Java\", 0.7, \"Joshua Bloch\");\n }\n}\n```\n\n\nRead top to bottom. `Product`'s field initializers run, then its body. `PhysicalProduct`'s field initializers, then its body. `Book`'s field initializers, then its body. The deepest class runs last, and within each class, the field initializers run before the constructor body.\n\nThis order matters because it tells you what you can rely on at any given moment. Inside `PhysicalProduct`'s constructor body, you can be sure `name` is already set (the parent ran first). Inside `Book`'s body, you can be sure both `name` and `weightKg` are set. The reverse is not true: inside `Product`'s body, neither `weightKg` nor `author` has been assigned yet. They still hold their primitive/reference defaults.\n\n---\n\n# The Overridable-Method-from-Constructor Pitfall\n\nOne subtle bug comes directly from the construction order. If a parent constructor calls a method that's overridden in the child, the **child's** version runs, but the child's fields haven't been initialized yet. The override sees an object that's only half-built.\n\nThis bug compiles cleanly, runs without an exception, and produces output that looks reasonable, but the fields are all defaults.\n\n\n```java\npublic class Product {\n String name;\n\n public Product(String name) {\n this.name = name;\n printLabel(); // calls overridable method during construction\n }\n\n public void printLabel() {\n System.out.println(\"Product: \" + name);\n }\n}\n\npublic class Book extends Product {\n String author;\n int yearPublished;\n\n public Book(String name, String author, int yearPublished) {\n super(name);\n this.author = author;\n this.yearPublished = yearPublished;\n }\n\n @Override\n public void printLabel() {\n System.out.println(\"Book: \" + name + \" by \" + author + \" (\" + yearPublished + \")\");\n }\n\n public static void main(String[] args) {\n new Book(\"Effective Java\", \"Joshua Bloch\", 2018);\n }\n}\n```\n\n\nThat output is wrong, and the wrongness is silent. The call to `new Book(...)` worked. No exception was thrown. But the `printLabel` invocation inside `Product`'s constructor ran the **`Book` override**, because dynamic method dispatch uses the runtime type of the object, which is `Book`. At that moment, `Product`'s body has assigned `name`, but `super(...)` hasn't returned yet, so `Book`'s field initializers and body haven't run. `author` is still `null`. `yearPublished` is still `0`. The override sees them in that not-yet-initialized state.\n\nIf the override depended on those fields being non-null (say, it called `author.length()` on them), the constructor would throw a `NullPointerException`, and the trace would point at `printLabel` from inside `Product`'s constructor, which is a confusing place to land.\n\nThe fix is to **not call overridable methods from constructors**. Two safe alternatives:\n\n\n| Approach | When to use it |\n| --- | --- |\n| Mark the method `private`, `static`, or `final` | When the parent really does need a helper at construction time, but it shouldn't be overridable. |\n| Move the call out of the constructor | When the work isn't strictly needed at construction time, do it from a separate `init` step or from a factory method. |\n\n\nThe same example with the safe pattern. `printLabel` is now `final`, so it can't be overridden. Subclasses can still add their own labeling methods, but the parent's call site is stable.\n\n\n```java\npublic class Product {\n String name;\n\n public Product(String name) {\n this.name = name;\n printLabel();\n }\n\n public final void printLabel() {\n System.out.println(\"Product: \" + name);\n }\n}\n\npublic class Book extends Product {\n String author;\n int yearPublished;\n\n public Book(String name, String author, int yearPublished) {\n super(name);\n this.author = author;\n this.yearPublished = yearPublished;\n printDetailedLabel();\n }\n\n public void printDetailedLabel() {\n System.out.println(\"Book: \" + name + \" by \" + author + \" (\" + yearPublished + \")\");\n }\n\n public static void main(String[] args) {\n new Book(\"Effective Java\", \"Joshua Bloch\", 2018);\n }\n}\n```\n\n\nThe parent's call always runs the parent's `printLabel`, and the child does its own labeling after `super(...)` has returned and its own fields are set.\n\nThis pitfall appears in the JDK itself. The reason classes like `LinkedHashMap` and `Calendar` were quirky to subclass for a long time is that early designs called overridable methods from their constructors. Effective Java by Joshua Bloch dedicates a full item to this rule. Don't call overridable methods from constructors.\n\nA short note on records: records have a synthesized canonical constructor that follows all the chaining rules above and implicitly chains to `Object` through the record machinery. You can write a compact form (`public Book { ... }` with no parameter list) that runs validation before the implicit field assignments, but it's still subject to the first-statement rule for any explicit `this(...)`. Records remove most of the surface area where this pitfall could bite you, but the underlying chain is the same.","pageType":"java"}

Constructor Chaining

Get Premium