What happens if you print an uninitialized local variable?

Three facts explain what happens:

• No default. Unlike instance variables (which default to 0, false, or null), local variables are never given a default value by the compiler.
• Definite assignment. The compiler analyzes every possible path through your method. If any path reaches a read of the variable without having assigned it first, compilation fails.
• Compile-time error, not runtime. The program never starts. The compiler prints: variable fee might not have been initialized. No bytecode is produced.

What exactly happens?

If you write this code, it will not compile:

public class Demo {
    public static void main(String[] args) {
        int fee;
        System.out.println(fee);  // COMPILE ERROR
    }
}

Demo.java:4: error: variable fee might not have been initialized
        System.out.println(fee);
                           ^
1 error

The compiler sees that fee was declared but never assigned, and it refuses to produce a .class file. The program never runs.

What is definite assignment?

Definite assignment is a rule defined in the Java Language Specification. It says: for every local variable, the compiler must be able to prove that the variable has been assigned a value along every execution path that reaches a point where the variable is read.

The key word is "every path." It is not enough to assign the variable somewhere. It must be assigned on all possible paths before the read.

// This ALSO fails to compile
int fee;
if (amount > 1000) {
    fee = 20;
}
System.out.println(fee);  // ERROR: the else path never assigned fee

The compiler sees two paths: one where amount > 1000 is true (fee is assigned) and one where it is false (fee is never assigned). Because the second path reaches the print without an assignment, compilation fails.

How do you fix it?

There are three common patterns:

Pattern 1: Initialize at declaration

Give the variable a default value when you declare it.

int fee = 0;  // default
if (amount > 1000) {
    fee = 20;
}
System.out.println(fee);  // OK: fee is always at least 0

Pattern 2: Assign on every branch

Make sure every branch of the if assigns the variable.

int fee;
if (amount > 1000) {
    fee = 20;
} else {
    fee = 0;
}
System.out.println(fee);  // OK: both paths assign

Pattern 3: Guard with throw or return

If one branch throws an exception or returns, the compiler prunes that path. The surviving path must assign.

int fee;
if (amount <= 0) {
    throw new IllegalArgumentException("Amount must be positive");
}
fee = 20;
System.out.println(fee);  // OK: the only surviving path assigns fee

Why did Java choose this design?

Different languages handle this differently:

• C allows reading an uninitialized local variable. You get whatever garbage was on the stack. This causes unpredictable bugs that are hard to find.
• Python raises a NameError at runtime if you read a variable before assigning it. The bug is caught, but only when that line actually executes.
• Java catches the problem at compile time. The program never starts if there is any path where a local is read without being assigned.

Java's approach is the safest because the bug is impossible at runtime. The compiler guarantees it cannot happen. In banking software, this means a transfer method can never accidentally read an unset fee and silently move the wrong amount of money.

Why do instance variables get defaults but locals do not?

Instance variables live on the heap as part of an object. When the JVM allocates memory for an object, it zeroes out the entire block. This is efficient (one memset call) and safe (no garbage values).

Local variables live on the stack. The JVM does not zero the stack frame because it would add overhead to every method call. Instead, the language specification requires the compiler to enforce definite assignment, which achieves the same safety at zero runtime cost.

The result is the same: you never read an uninitialized value in Java. The mechanism is different: defaults for fields, compile-time checks for locals.

What about arrays?

The array reference itself is a local variable and follows the same rules. If you declare int[] fees; and try to use it without assigning, you get a compile error.

But array elements are different. When you create an array with new int[5], the elements are automatically initialized to their default values (0 for int). This is because the array lives on the heap, just like an object.

int[] fees;  // local reference, no default
// System.out.println(fees.length);  // COMPILE ERROR: fees not initialized

fees = new int[3];  // now assigned
System.out.println(fees[0]);  // OK: prints 0 (array elements get defaults)

What about try-catch blocks?

A common pattern is declaring a variable before a try block and assigning it inside:

BigDecimal balance;
try {
    balance = fetchBalanceFromDatabase(accountId);
} catch (SQLException e) {
    // If we do not assign balance here, the compiler will complain below
    balance = BigDecimal.ZERO;  // fallback
}
System.out.println(balance);  // OK: both paths assign

If the catch block does not assign balance (or throw), and you try to read it after the try-catch, the compiler rejects it because the exception path left the variable unassigned.

What about lambdas and effectively final?

A local variable captured by a lambda or anonymous class must be effectively final, meaning it is assigned exactly once and never modified after that. This is a related but separate rule.

int fee = 20;  // definitely assigned, effectively final
Runnable task = () -> System.out.println("Fee: " + fee);  // OK

int rate;
rate = 5;
// rate = 10;  // If you uncomment this, fee is no longer effectively final
Runnable task2 = () -> System.out.println("Rate: " + rate);  // OK if assigned once

The compiler checks definite assignment first (is the variable assigned before the lambda reads it?) and effectively-final second (is it never reassigned?).

What about switch expressions (Java 14+)?

Switch expressions provide a clean way to initialize a local from multiple branches, because every branch must produce a value:

String accountType = "SAVINGS";

// Switch expression: every case must return a value, so fee is always assigned
int fee = switch (accountType) {
    case "SAVINGS"  -> 0;
    case "CURRENT"  -> 10;
    case "LOAN"     -> 25;
    default         -> 5;
};

System.out.println("Fee: " + fee);  // OK: definitely assigned

The compiler enforces that every case (including default) produces a value. If you miss a case and there is no default, the switch expression does not compile. This makes switch expressions ideal for initializing locals from multiple conditions.

What are common mistakes?

• Assigning on only one branch. If you have an if without an else, and the local is only assigned inside the if, the compiler rejects it.
• Confusing local rules with field rules. Fields get defaults. Locals do not. This trips up beginners who expect int fee; to mean fee = 0.
• Forgetting the catch branch. If you assign a variable inside try but do nothing in catch, the variable is unassigned on the exception path.
• Loop with zero iterations. A variable assigned inside a for loop that might run zero times is not considered definitely assigned after the loop.

int total;
for (int i = 0; i < list.size(); i++) {  // list might be empty
    total = list.get(i);
}
// System.out.println(total);  // ERROR: loop might not execute

What should a senior engineer know?

• final locals and definite assignment work together. A final local variable can be left uninitialized at declaration and assigned once later, as long as it is definitely assigned on every path before use. This enables clean patterns like assigning different values in each branch of an if to a final variable.
• The bytecode has no concept of uninitialized locals. The JVM specification does not enforce definite assignment. It is purely a javac rule. If you generate bytecode manually (e.g., with ASM), you can create code that reads an uninitialized local. The verifier will not stop it. But javac will never produce such bytecode.
• IDEs enforce this in real time. IntelliJ and Eclipse show the error as you type, before you even try to compile. SonarQube also flags this as a critical issue.
• Kotlin takes a similar approach. If you use val or var without initializing and try to read it, the Kotlin compiler also enforces definite assignment.