{"title":"Initializer Blocks","description":"","content":"Sometimes a field needs more than a single expression to set itself up: populating a list of default categories, loading a discount table at startup, or running a multi step computation before any constructor body executes. Initializer blocks provide a place for that setup logic without duplicating it across every constructor. This lesson covers the two flavors of initializer block (instance and static), when each one runs, and the order Java uses to wire everything together for `new`.\n\n---\n\n# Why Initializer Blocks Exist\n\nA field initializer is a single expression. That's fine for `private int stock = 0;` or `private String name = \"default\";`. But more involved setup needs more than one expression. Say a `Catalog` class needs every instance to start with three default categories already in its list. With only a field initializer, this is impossible.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class CatalogAttempt {\n private List categories = new ArrayList<>();\n // Where do we add \"Electronics\", \"Books\", \"Clothing\"?\n}\n```\n\n\nThree `add` calls don't fit into a single expression. The usual workaround is to do the work inside every constructor.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class CatalogWithConstructors {\n private List categories;\n private String storeName;\n\n public CatalogWithConstructors() {\n categories = new ArrayList<>();\n categories.add(\"Electronics\");\n categories.add(\"Books\");\n categories.add(\"Clothing\");\n storeName = \"AlgoMart\";\n }\n\n public CatalogWithConstructors(String storeName) {\n categories = new ArrayList<>();\n categories.add(\"Electronics\");\n categories.add(\"Books\");\n categories.add(\"Clothing\");\n this.storeName = storeName;\n }\n}\n```\n\n\nThe setup of `categories` is identical in both constructors. Adding a fourth default category later requires updates in both places. Miss one and the two constructors drift apart.\n\nAn instance initializer block fixes this. The shared setup goes into a `{ ... }` block at the class level (outside any method or constructor), and Java runs it for every `new`, before the constructor body.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class Catalog {\n private List categories;\n private String storeName;\n\n {\n categories = new ArrayList<>();\n categories.add(\"Electronics\");\n categories.add(\"Books\");\n categories.add(\"Clothing\");\n }\n\n public Catalog() {\n storeName = \"AlgoMart\";\n }\n\n public Catalog(String storeName) {\n this.storeName = storeName;\n }\n\n public static void main(String[] args) {\n Catalog a = new Catalog();\n Catalog b = new Catalog(\"AlgoMart Express\");\n System.out.println(a.storeName + \" has \" + a.categories.size() + \" categories\");\n System.out.println(b.storeName + \" has \" + b.categories.size() + \" categories\");\n }\n}\n```\n\n\nBoth constructors get the three default categories without repeating the setup. Adding a fourth category is a one line change.\n\nInitializer blocks are not the only tool for this job. Constructor chaining with `this(...)` and helper methods can also remove duplication. Initializer blocks fit best when shared setup has to run for every constructor, including any future constructors added later. The block runs for all of them automatically.\n\n---\n\n# Instance Initializer Blocks\n\nAn instance initializer block is a pair of braces at the class level. It's not labeled, it's not named, and it isn't inside any method.\n\n\n```java\npublic class Product {\n private String name;\n private double price;\n private boolean inStock;\n\n {\n inStock = true;\n }\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n```\n\n\nEvery time `new Product(...)` runs, the block runs. So `inStock` defaults to `true` for every product, no matter which constructor was called or how many constructors get added later.\n\nRules for instance initializer blocks:\n\n- They live at the class level, not inside a method or constructor.\n- A class can have any number of them. They run top to bottom in the order they appear.\n- They can read and assign any instance field of the class.\n- They can call instance methods, though calling methods that depend on fields not yet initialized leads to subtle bugs.\n- They cannot return a value. Writing `return;` inside an instance initializer block is a compile error.\n- They cannot have parameters.\n\nAn example with two instance initializer blocks shows the ordering:\n\n\n```java\npublic class TwoBlocks {\n private int x;\n private int y;\n\n {\n x = 1;\n System.out.println(\"Block A ran, x = \" + x);\n }\n\n {\n y = x + 10;\n System.out.println(\"Block B ran, y = \" + y);\n }\n\n public TwoBlocks() {\n System.out.println(\"Constructor ran, x = \" + x + \", y = \" + y);\n }\n\n public static void main(String[] args) {\n new TwoBlocks();\n }\n}\n```\n\n\nBlock A runs first and sets `x` to `1`. Block B runs next and uses the value `x` already has, then sets `y` to `11`. The constructor body runs last and sees both values. The blocks behave as if their statements were inlined into the top of every constructor, in declaration order.\n\n---\n\n# Static Initializer Blocks\n\nA static initializer block looks like an instance initializer block with one extra word: `static`. The behavior differs. Where an instance block runs for every `new`, a static block runs **once**, when the class itself is first loaded by the JVM.\n\nUse a static initializer block for one time, class level setup that's too involved for a single field initializer. Typical examples include populating a static map with defaults, building a lookup table, or registering the class with some external system.\n\n\n```java\nimport java.util.HashMap;\nimport java.util.Map;\n\npublic class DiscountTable {\n private static final Map CODES = new HashMap<>();\n\n static {\n CODES.put(\"WELCOME10\", 0.10);\n CODES.put(\"SAVE5\", 0.05);\n CODES.put(\"VIP25\", 0.25);\n System.out.println(\"Discount table loaded with \" + CODES.size() + \" codes\");\n }\n\n public static double percentFor(String code) {\n return CODES.getOrDefault(code, 0.0);\n }\n\n public static void main(String[] args) {\n System.out.println(\"WELCOME10 -> \" + percentFor(\"WELCOME10\"));\n System.out.println(\"UNKNOWN -> \" + percentFor(\"UNKNOWN\"));\n }\n}\n```\n\n\nThe `static` block populates `CODES` once, before any code outside the class can touch it. Even if `percentFor` is called a thousand times, the block doesn't run again. That makes static blocks a good fit for expensive setup that should happen exactly once per program run.\n\nRules for static initializer blocks:\n\n- They sit at the class level, prefixed with `static`.\n- They run **once**, the first time the class is loaded by the JVM. Creating an instance, calling a static method, or reading a static field all count as triggers.\n- A class can have any number of static blocks. They run top to bottom in declaration order.\n- They can only read and assign **static** fields. They cannot touch instance fields, because instances might not exist yet.\n- They cannot have parameters or return values. `return;` inside a static block is a compile error.\n- They can call static methods of the class, with the same caveat about depending on uninitialized static fields.\n\nThe \"runs once\" behavior in code:\n\n\n```java\npublic class RunsOnce {\n static {\n System.out.println(\"Static block ran\");\n }\n\n {\n System.out.println(\"Instance block ran\");\n }\n\n public RunsOnce() {\n System.out.println(\"Constructor ran\");\n }\n\n public static void main(String[] args) {\n System.out.println(\"Creating first instance\");\n new RunsOnce();\n System.out.println(\"Creating second instance\");\n new RunsOnce();\n }\n}\n```\n\n\nThe static block ran before `main` even started printing. The class had to be loaded for `main` to run, and loading the class triggered the static block. The instance block ran twice (once per `new`), but the static block ran exactly once.\n\nA static block runs eagerly the first time the class is touched. If the block does heavy work (reading a large file, hitting the network), every program that loads the class pays that cost up front. For lazy or optional setup, prefer a lazily initialized static method over a static block.\n\n---\n\n# Execution Order: The Big Picture\n\nWhen `new Product(...)` runs, several things happen in a precise order. The result usually works, so the sequence is invisible. But knowing the order helps when debugging initialization bugs and reading unfamiliar code.\n\nThe full lifecycle from \"the JVM has never seen this class\" to \"the constructor body has returned\":\n\n\n```mermaid\nflowchart TD\n Load[JVM loads class
for the first time]:::cyan --> StaticInit[Static fields get
default values
0, null, false]:::orange\n StaticInit --> StaticBlocks[Static field initializers
and static blocks run
top to bottom]:::orange\n StaticBlocks --> Ready[Class is ready
static work is done]:::green\n\n Ready --> NewCalled[new ClassName called]:::cyan\n NewCalled --> InstAlloc[Instance fields get
default values
0, null, false]:::teal\n InstAlloc --> InstInit[Instance field initializers
and instance blocks run
top to bottom]:::teal\n InstInit --> CtorBody[Constructor body runs]:::green\n CtorBody --> Done[Object is ready
new returns reference]:::green\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nSeveral details to underscore:\n\n1. **Static work happens once, ahead of everything else.** The first time the class is touched (any `new`, any static method call, any static field read), the JVM loads it and runs the static initializers. After that, the static block is done forever.\n2. **Instance work happens on every `new`.** Each instance gets its own pass through the field initializers and instance blocks before the constructor body runs.\n3. **Field initializers and instance blocks run in textual order.** The blocks don't all run \"before\" or \"after\" the field initializers. They interleave with them, top to bottom, in the order they appear in the source file.\n4. **The constructor body runs last.** By the time the opening `{` of the constructor is reached, every field initializer and every instance block has already executed.\n\nParent class initialization (when one class extends another) adds another layer on top.\n\n---\n\n# Interleaving Field Initializers and Instance Blocks\n\nJava does **not** run all field initializers first and then all blocks. It walks down the class textually and executes each initializer or block in order.\n\n\n```java\npublic class TextualOrder {\n int a = printAndReturn(\"a = 1\", 1);\n\n {\n System.out.println(\"Block 1 runs, a = \" + a);\n a = 2;\n }\n\n int b = printAndReturn(\"b = \" + (a + 10), a + 10);\n\n {\n System.out.println(\"Block 2 runs, b = \" + b);\n }\n\n public TextualOrder() {\n System.out.println(\"Constructor body, a = \" + a + \", b = \" + b);\n }\n\n private static int printAndReturn(String label, int value) {\n System.out.println(\"Field init: \" + label);\n return value;\n }\n\n public static void main(String[] args) {\n new TextualOrder();\n }\n}\n```\n\n\nReading this step by step: the field initializer for `a` runs first because it's declared first. Then Block 1 runs and changes `a` to `2`. Then the field initializer for `b` runs, and at that moment `a` is already `2`, so `a + 10` is `12`. Then Block 2 runs. Finally the constructor body runs and sees `a = 2, b = 12`.\n\nIf Java ran \"all initializers first, then all blocks\", the field initializer for `b` would have used `a + 10 = 11`, not `12`. The interleaving is what makes the example print `12`. This is the rule the JLS specifies: instance variable initializers and instance initializer blocks execute in textual order.\n\nThe same interleaving rule applies to static field initializers and static blocks, just one level up. Static items run in textual order during class loading.\n\n\n```java\npublic class StaticOrder {\n static int s1 = log(\"s1 = 100\", 100);\n\n static {\n System.out.println(\"Static block 1: s1 = \" + s1);\n s1 = 200;\n }\n\n static int s2 = log(\"s2 = \" + (s1 + 1), s1 + 1);\n\n static {\n System.out.println(\"Static block 2: s2 = \" + s2);\n }\n\n private static int log(String label, int value) {\n System.out.println(\"Static field init: \" + label);\n return value;\n }\n\n public static void main(String[] args) {\n System.out.println(\"main: s1 = \" + s1 + \", s2 = \" + s2);\n }\n}\n```\n\n\nSame idea, applied to static items. The initializer for `s1` runs, the first static block changes `s1` to `200`, the initializer for `s2` uses the current value (`200 + 1 = 201`), and the second static block prints it.\n\n---\n\n# Multiple Blocks: Top to Bottom\n\nBoth flavors of initializer block can appear more than once in a class. Java runs them in the order they appear in the source file. There's no priority, no labels, no runtime reordering.\n\n\n```java\npublic class MultiBlocks {\n static { System.out.println(\"Static block A\"); }\n static { System.out.println(\"Static block B\"); }\n\n { System.out.println(\"Instance block A\"); }\n { System.out.println(\"Instance block B\"); }\n\n public MultiBlocks() {\n System.out.println(\"Constructor body\");\n }\n\n public static void main(String[] args) {\n System.out.println(\"--- new #1 ---\");\n new MultiBlocks();\n System.out.println(\"--- new #2 ---\");\n new MultiBlocks();\n }\n}\n```\n\n\nThe static blocks ran once each, in the order they were written, before `main` started printing. The instance blocks ran in order for each `new`. In practice, more than one block of each kind is rare. A single block usually reads more clearly than two scattered ones.\n\n---\n\n# A Worked Construction Example\n\nA program that mixes static fields, instance fields, both kinds of initializer blocks, and a constructor. The output shows the exact order every step runs.\n\n\n```java\npublic class CartLifecycle {\n static int classLoadCount = recordStaticInit(\"static field\");\n\n static {\n System.out.println(\"Static block: classLoadCount = \" + classLoadCount);\n classLoadCount = 1;\n }\n\n int instanceField = recordInstanceInit(\"instance field\");\n\n {\n System.out.println(\"Instance block ran\");\n }\n\n public CartLifecycle(String label) {\n System.out.println(\"Constructor body for \" + label);\n }\n\n private static int recordStaticInit(String label) {\n System.out.println(\"Initializing \" + label);\n return 0;\n }\n\n private static int recordInstanceInit(String label) {\n System.out.println(\"Initializing \" + label);\n return 42;\n }\n\n public static void main(String[] args) {\n System.out.println(\"--- main starts ---\");\n new CartLifecycle(\"cart-1\");\n System.out.println(\"--- between news ---\");\n new CartLifecycle(\"cart-2\");\n }\n}\n```\n\n\nStep by step:\n\n1. The JVM loads `CartLifecycle` because `main` lives in it.\n2. The static field initializer runs and prints `Initializing static field`. `classLoadCount` becomes `0`.\n3. The static block runs next, prints the current value of `classLoadCount` (`0`), and sets it to `1`. The static work is done.\n4. `main` starts executing. The first `println` fires.\n5. `new CartLifecycle(\"cart-1\")` triggers instance initialization. The instance field initializer runs and prints `Initializing instance field`. Then the instance block prints `Instance block ran`. Finally the constructor body runs and prints its line.\n6. The second `new` repeats steps for the instance work only. The static block does not run again.\n\nThis single example captures the whole ordering model.\n\n---\n\n# Common Restrictions and Compile Errors\n\nSeveral rules around initializer blocks trip up new users. The compiler enforces them strictly.\n\n### `return` Is Not Allowed in an Initializer Block\n\nInitializer blocks aren't methods. They don't have a return type, and they don't have a caller waiting for a value. A `return` statement inside an initializer block is a compile error.\n\n**What's wrong with this code?**\n\n\n```java\npublic class CannotReturn {\n {\n return; // compile error\n }\n}\n```\n\n\nThe compiler complains with: \"return outside method\". Initializer blocks are positions in the class lifecycle, not methods you can exit early from.\n\n**Fix:**\n\n\n```java\npublic class CannotReturnFixed {\n {\n // Just don't return. Let the block finish on its own.\n System.out.println(\"Instance block running\");\n }\n}\n```\n\n\nTo skip the rest of a block under some condition, use a regular `if` to guard the remaining statements.\n\n### Static Blocks Cannot See Instance State\n\nA static block runs when the class loads, before any instance exists. Touching an instance field from inside a static block is a compile error.\n\n**What's wrong with this code?**\n\n\n```java\npublic class StaticTouchesInstance {\n private int productCount = 0;\n\n static {\n productCount = 5; // compile error\n }\n}\n```\n\n\nThe compiler reports: \"non-static variable productCount cannot be referenced from a static context\". There's no specific instance for the static block to apply the change to.\n\n**Fix:**\n\nThe fix depends on intent. If `productCount` should be shared across all instances (a class level counter), make it `static`. If it should be per instance, move the line into an instance block or a constructor.\n\n\n```java\npublic class StaticTouchesInstanceFixed {\n private static int productCount = 0;\n\n static {\n productCount = 5;\n }\n}\n```\n\n\n### Initializer Blocks Cannot Live Inside Methods\n\nPutting `static { ... }` or a class level instance block inside a method body is a compile error. Initializer blocks belong to the class, not to a method.\n\n**What's wrong with this code?**\n\n\n```java\npublic class BlockInMethod {\n public void setupCart() {\n static { // compile error\n System.out.println(\"Cannot do this\");\n }\n }\n}\n```\n\n\nThe `static` keyword in front of a block is only legal at the class level. Inside a method, `{ ... }` is just a regular block of code (a scope), but `static { ... }` doesn't mean anything.\n\n**Fix:**\n\nMove the block out of the method, up to the class level.\n\n\n```java\npublic class BlockInMethodFixed {\n static {\n System.out.println(\"Class loaded\");\n }\n\n public void setupCart() {\n // regular method body, no static block here\n }\n}\n```\n\n\n### Forgetting That Static Runs Only Once\n\nA common bug: writing a static block expecting it to reset some state every time a new instance is created, then wondering why the state persists across instances. The fix is to move that logic into an instance block or the constructor.\n\n**What's wrong with this code?**\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class CartReset {\n private static List items = new ArrayList<>();\n\n static {\n items.add(\"default item\");\n }\n\n public CartReset() {\n System.out.println(\"Cart has \" + items.size() + \" items\");\n }\n\n public static void main(String[] args) {\n new CartReset();\n new CartReset();\n }\n}\n```\n\n\nThe output is `Cart has 1 items` then `Cart has 2 items`. Each new `CartReset` reuses the same shared `items` list. The static block did its work once and never ran again, but the constructor isn't shown anything new because the list is `static`.\n\n**Fix:**\n\nFor each cart to have its own list of items, make the list an instance field and seed it from an instance block.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class CartResetFixed {\n private List items;\n\n {\n items = new ArrayList<>();\n items.add(\"default item\");\n }\n\n public CartResetFixed() {\n System.out.println(\"Cart has \" + items.size() + \" items\");\n }\n\n public static void main(String[] args) {\n new CartResetFixed();\n new CartResetFixed();\n }\n}\n```\n\n\nNow each instance has its own list, the instance block runs for every `new`, and both prints say `Cart has 1 items`.\n\n---\n\n# How Blocks Help With `final` Fields\n\nInitializer blocks are one of the legal places where a \"blank final\" can be assigned. A blank final is a `final` field declared without an inline value. Such a field must be definitely assigned exactly once before any constructor finishes, and the assignment can happen in a field initializer, an initializer block, or a constructor.\n\n\n```java\npublic class FinalInBlock {\n private final int defaultStock;\n\n {\n defaultStock = 50;\n }\n\n public FinalInBlock() {\n System.out.println(\"Default stock: \" + defaultStock);\n }\n\n public static void main(String[] args) {\n new FinalInBlock();\n }\n}\n```\n\n\nThe full story of `final` and where blank finals can and cannot be assigned belongs to the `final` keyword chapter. It is mentioned here because an instance block is one of the legal homes for that one time assignment.\n\n---\n\n# Initializer Blocks vs the Alternatives\n\nThere are several places where initialization logic can live.\n\n\n| Option | Runs when | Best for |\n| --- | --- | --- |\n| Inline field initializer | Each `new` (or once for static) | Simple one expression setup |\n| Instance initializer block | Each `new`, before the constructor body | Multi step setup shared across all constructors |\n| Static initializer block | Once per class load | One time class level setup (lookup tables, defaults) |\n| Constructor body | Each `new`, after instance blocks | Constructor specific logic that depends on parameters |\n| Constructor chaining (`this(...)`) | Each `new` | Reusing one full constructor from another |\n\n\nDefault to field initializers when the setup is a single expression. Use an instance block when two or more constructors share the same opening lines. Prefer `this(...)` chaining when defaults vary by constructor. Use static blocks only for class-level, one-time setup.","pageType":"java"}

Initializer Blocks

Get Premium