Detailed explanation
An instance initializer block is a non-static block written directly inside a class, such as { x = 10; }. A constructor is a special declaration with the class name and no return type, used to initialise a new instance. Both participate in object initialisation, but they serve different purposes: initializer blocks express shared setup, while constructors define how callers create objects with particular arguments. Constructors can accept parameters, be overloaded, and have access modifiers; initializer blocks cannot.
During ordinary construction, instance fields first receive default values, such as 0 or null. After the superclass constructor completes, the current class’s instance field initializers and instance initializer blocks execute in their textual order. The remaining constructor body then executes. For conventional constructors, this is often summarised as “superclass constructor, instance initialization, constructor body.” Modern Java also permits restricted statements before an explicit constructor invocation, so “right before the constructor body” is a useful simplification rather than a universal rule. An initializer block can access instance fields and methods, but cannot directly use a constructor’s parameters.
If one constructor delegates to another using this(...), the initializer blocks do not execute again for each constructor in that chain. They execute once for that class’s portion of the new object, in the constructor that invokes super(...), before control returns through the delegating constructors. Compilers implement this by incorporating instance initialization into the relevant constructors. This makes blocks useful for setup shared across constructor overloads, although constructor delegation is often clearer when initialization depends on inputs or validation. Interviewers commonly test this distinction with output-order questions involving inheritance and constructor chaining.
In the supplied Demo example, the first ordinary new Demo() prints the static-block message, then “instance block”, then “constructor”; x becomes 10. Later constructions repeat only the last two messages. More precisely, a static block runs during class initialization, not merely class loading, normally once per class definition per defining class loader. Also, instance initializer blocks are part of constructor-based initialization, not every possible object-creation mechanism: cloning does not execute them.
Key points to remember
- Constructors support parameters, overloading, and access control; instance initializer blocks do not.
- Instance field initializers and initializer blocks run in source order after superclass construction.
- A this(...) constructor chain executes the class’s instance initialization once, not once per constructor.
- Initializer blocks suit shared setup; constructor delegation usually suits input-dependent initialization.
- Static blocks run during class initialization, whereas instance blocks run during ordinary instance construction.
Common mistakes candidates make
- Saying that class loading itself always executes static initializer blocks.
- Assuming each constructor reached through this(...) runs the instance initializer blocks again.
- Ignoring superclass construction and textual ordering when predicting initialization output.
Likely follow-up questions
What happens when a class has multiple instance initializer blocks?
They execute in textual order, interleaved with instance field initializers. Moving a field initializer or block can therefore change the final field values or printed output.
Can an instance initializer block throw a checked exception?
Yes, in a named class, provided every constructor declares that checked exception or a suitable superclass exception. If initialization throws, construction fails and the caller does not receive a successfully constructed object.
Why use constructor delegation instead of an initializer block?
Delegation lets several constructors reuse a single initialization path that accepts and validates arguments. It usually makes parameter-dependent setup easier to follow, while an initializer block is independent of constructor parameters.
Interview tip: Explain the purpose difference first, then trace the supplied example and clarify that this(...) chaining does not repeat instance initialization.