The Java if Statement: Conditional Execution Explained

The if statement evaluates a condition and, only if it is true, executes the statement that follows. There is nothing else required, which is what distinguishes it from if-else.

int age = 20;
if (age >= 18) {
    System.out.println("Eligible to vote!");
    System.out.println("Welcome to active citizenship.");
}

With age at 20 both lines print. When the condition is false, the block is skipped entirely and execution simply continues after it.

int score = 45;
if (score >= 50) {
    System.out.println("This line never prints.");
}

Nothing is printed here, and that is the whole behaviour. There is no implicit "otherwise" and no error, so an if that never fires is entirely legal.

The parentheses are not optional, which is a small syntactic difference from C-like languages that let you write if x > 0.

if (age >= 18) {
} // correct
if age >= 18 {
} // syntax error

Java has no concept of truthy and falsy values. The condition has to be a boolean expression, and anything else is a compile error.

if (1) {
} // error: incompatible types: int cannot be converted to boolean
if (someName) {
} // error: incompatible types: String cannot be converted to boolean
if (values) {
} // error: incompatible types: int[] cannot be converted to boolean

This is stricter than C and C++, where any nonzero value counts as true and a null pointer counts as false. Porting that habit produces a compile error rather than a silent misbehaviour, which is the kind way to discover the difference.

int count = items.size();
if (count > 0) {
} // correct, and it also says what you mean

Prefer the explicit comparison even where a bare test would compile in another language, because if (count > 0) tells the reader the intent rather than making them infer it.

The Boolean **wrapper** is the one type that is accepted but can still fail at run time.

Boolean flag = null;
if (flag) {
} // throws NullPointerException on unboxing

Because a Boolean has to be unboxed to be tested, and unboxing null throws. The fix is either a primitive boolean, or an explicit null check, and the && ordering is what makes it safe.

if (flag != null && flag) {
} // safe, the right side runs only if flag is not null

The condition is computed exactly one time, however many times the branch body runs. This matters when the condition has a side effect.

static int calls = 0;
static boolean check() {
    calls++;
    return true;
}if (check()) {
} // one call

Verified behaviour, check() is invoked once and calls ends at 1. A method call in the condition is therefore safe, but it also means you should not rely on it being called repeatedly inside a loop condition, because each iteration does call it again.

static int calls = 0;
if (check() && check()) {
} // two calls, left operand is true

With check() returning true the left operand does not decide the outcome, so the right one is evaluated and calls reaches 2.

Because && and || short-circuit, the right-hand operand is only evaluated when it can still affect the result.

if (false && rhs()) {
} // rhs() is NEVER called
if (true || rhs()) {
} // rhs() is NEVER called
if (true && rhs()) {
} // rhs() IS called
if (false || rhs()) {
} // rhs() IS called

Verified: in both of the first two cases the side effect inside rhs() never fires. This is the mechanism behind every null-safe comparison in Java, and it is a correctness tool rather than only a performance one.

String name = null;
if (name != null && name.isEmpty()) {
} // safe, no NPE

Reordering those two operands breaks it, because name.isEmpty() is then reached with name null.

if (name.isEmpty() && name != null) {
} // throws NullPointerException

The braces decide how many statements belong to the if. Without them only the immediately following statement does, and everything after runs unconditionally.

int age = 20;
if (age >= 18) System.out.println("can vote");
System.out.println("ALWAYS runs");

Both lines print here. The second is not inside the if at all, which is legal but easy to misread. With braces the grouping is explicit.

if (age >= 18) {
    System.out.println("can vote");
}System.out.println("ALWAYS runs");

Now only the first line is conditional. The practical rule is to always use braces, even for a single statement, and most Java style guides require it.

The braceless form rarely causes a problem when it is written, because the author can see it. The danger is a later edit that adds a second line to a branch that had only one.

// written this way, with no bug
if (databaseIsUp) connect();
logRequest();
// someone later adds a line, forgetting the braces
if (databaseIsUp) connect();
logRequest();
// now runs unconditionally, and is easy to misread as conditional

Verified output is connect only when databaseIsUp is true, but the moment a second statement is added underneath it silently executes every time. This is the same class of bug as the famous Apple TLS "goto fail" error, where a missing brace caused a security check to be skipped, and it is why braces are not merely a style preference.

// with braces, adding a line cannot change the meaning
if (databaseIsUp) {
    connect();
}logRequest();

An else always attaches to the nearest unmatched if, so leaving braces off can change which branch it belongs to.

if (a == 0) if (a == 1) System.out.println("A");
else System.out.println("B");

The else binds to the inner if, not the outer one, because the inner one is the closest without an else. With a equal to 0 the output is B, since the inner condition fails and its else runs. This is where the braceless form stops being a readability nit and starts changing behaviour, so always use braces whenever an if and an else appear together.

A variable declared inside the braces belongs to that block and cannot be used outside it.

if (true) {
    int message = "hello";
    System.out.println(message);
    // fine
}System.out.println(message);
// error: cannot find symbol

Note the useful consequence for a variable declared outside: you can reassign it inside the if and the new value is visible afterwards.

int n = 1;
if (true) {
    n = 2;
}System.out.println(n);
// 2

Redeclaring the same name inside the block is a different story, and the rule is stricter than in many languages.

int n = 1;
if (true) {
    int n = 2;
} // error: variable n is already defined in method main

Shadowing a local is rejected outright. Shadowing a **field** is allowed, since fields and locals live in different namespaces, but it is worth avoiding because the inner declaration silently hides the field.

static int n = 100;
// a field
if (true) {
    int n = 2;
} // legal, and now hides the field

If a variable is declared without an initialiser, the compiler requires proof it was assigned before you read it, even inside an if.

int y;
boolean condition = true;
if (condition) y = 1;
System.out.println(y);
// error: variable y might not have been initialized

The compiler cannot see that condition happens to be true, because the value is only known at run time. Giving it a default, or covering every path with an else, satisfies the rule.

int y = 0;
if (condition) y = 1;
System.out.println(y);
// fine

An if is a **statement**, so it performs an action and yields nothing. You cannot assign its outcome or pass it to a method.

int result = if (condition) 1;
// error: illegal start of expression
System.out.println(if (condition) 1);
// error: illegal start of expression

When you need a value from a condition, the ternary operator is an **expression** and works exactly where if cannot.

int result = condition ? 1 : 0;
// fine

This is the single most important structural difference between the two, and it is the reason an if followed by an assignment is so common when a ternary would do.

An if that guards the only interesting work in a method reads better as an early return than as a branch wrapped around everything else.

// wrapped, the real work sits one level in
String describe(int value) {
    if (value < 0) {
        return "negative";
    } else {
        return "non-negative";
    }
}// early return, the main path is unindented
String describe(int value) {
    if (value < 0) {
        return "negative";
    } return "non-negative";
}

Both return the same thing. The second is easier to scan and stays flat when more checks are added. When there is no else and nothing after the branch, drop the braces and the nesting entirely.

An if is the natural home for an instanceof pattern, which tests the type and binds the value in one step. This is final from Java 16.

Object payload = "hello";
if (payload instanceof String s) {
    System.out.println(s.length());
    // s is already a String, no cast needed
}

The bound variable is in scope only where the test succeeded, so the else branch is where it becomes unavailable.

if (payload instanceof Integer i) {
    System.out.println("never reached");
} else {
    System.out.println("i is not in scope here");
}

Combined with negation the pattern still works, because the binding is only in scope when the test is true.

if (!(payload instanceof String s)) {
    System.out.println("not a string");
} else {
    System.out.println("negated form, s=" + s);
}

Verified output is negated form, s=hello. The pattern composes with && as well, which is the usual way to check a type and then a property of it.

if (payload instanceof String s && s.length() > 3) {
    System.out.println("a string of some length: " + s);
}

A short catalogue of the shapes you will write most often, all of which are single if statements with no else.

The null guard and the Boolean wrapper check are the two that most often appear in real code, and both are about avoiding a run-time failure rather than about logic.

if (result != null && result.size() > 0) {
} // guard, then check

The if (flag != null) line is worth calling out because it compiles, and it tests something other than what the name suggests.

Boolean flag = Boolean.TRUE;
if (flag != null) {
} // tests NON-NULL, not the truth of the value

A Boolean compared with != null asks whether the reference is present, not whether the value is true. A boolean primitive would not even allow this comparison, which is one more reason to prefer the primitive.

The short version: an if runs a block when a strictly boolean condition is true, evaluates that condition once, short-circuits when you combine conditions, and always keeps its meaning only if you use braces. It cannot produce a value, so reach for a ternary when you need one.