2.1 Conditional Branching with if/else and the Ternary Operator

2.1 Conditional Branching with if/else and the Ternary Operator

Decision-making constructs direct the path of code execution at runtime based on boolean conditions. While the fundamental structure of if, else if, and else statements appears straightforward, Java enforces strict type rules and parsing semantics that distinguish it from other C-family languages. The Oracle Java SE 17 Developer exam (1Z0-829) tests these subtleties, including strict boolean typing, the dangling else resolution mechanism, bracketless scoping hazards, and complex runtime type coercion in ternary expressions.

---

Strict Boolean Type Evaluation

In languages such as C, C++, or Python, non-boolean expressions such as integers (0 or 1) and object references (null or non-null pointers) can evaluate to "truthy" or "falsy" values within conditional statements. Java does not support truthy or falsy conversions. The condition expression within an if statement must evaluate strictly to the primitive boolean type or its boxed wrapper java.lang.Boolean.

int threshold = 10;

// COMPILE ERROR: incompatible types: int cannot be converted to boolean
if (threshold) { 
    System.out.println("Threshold reached");
}

String name = "Oracle";

// COMPILE ERROR: incompatible types: java.lang.String cannot be converted to boolean
if (name) { 
    System.out.println("Valid name");
}

The Assignment vs. Equality Trap

A frequent source of exam trick questions involves the assignment operator (=) mistakenly or intentionally placed inside a conditional expression instead of the equality comparison operator (==).

Because the assignment expression var = value returns the value being assigned, the type of the assignment determines whether the code compiles:

1. Numeric Assignment: An assignment like if (x = 5) assigns 5 to x and evaluates to the integer value 5. Because an int cannot be converted to boolean, this produces a compile-time error.
2. Boolean Assignment: An assignment like if (isActive = true) assigns true to isActive and evaluates to the boolean value true. Because the expression yields a boolean, this code compiles and executes, taking the branch regardless of the variable's prior value!

int count = 0;
// if (count = 1) { } // FAILS TO COMPILE: incompatible types: int to boolean

boolean hasPermission = false;
if (hasPermission = true) {
    // COMPILES AND EXECUTES!
    // hasPermission is assigned true, and the if-condition evaluates to true.
    System.out.println("Access granted"); 
}

---

Nested if Statements and the Dangling else Problem

When if and else statements are nested without explicit curly braces ({}), Java applies a deterministic grammatical rule: an else clause binds to the nearest preceding unmatched if statement within the same block.

Indentation and whitespace are completely ignored by the Java compiler. Misleading indentation can easily obscure how branches execute:

int temperature = 32;
boolean isRaining = false;

if (temperature > 50)
    if (isRaining)
        System.out.println("Warm rain");
else
    System.out.println("Cold weather");

Despite the indentation aligning the else clause with the outer if (temperature > 50), the compiler attaches the else to the inner if (isRaining). The execution proceeds as follows:

1. temperature > 50 (32 > 50) evaluates to false.
2. The outer if condition fails. Because the entire inner if-else construct forms the single subordinate statement of the outer if, the entire nested block is skipped.
3. Nothing is printed to the console!

To associate the else with the outer if, explicit curly braces are required:

if (temperature > 50) {
    if (isRaining) {
        System.out.println("Warm rain");
    }
} else {
    System.out.println("Cold weather"); // Executes when temperature <= 50
}

---

Single-Statement Blocks and Local Variable Declarations

When omitting curly braces {} in an if or else branch, exactly one statement belongs to that branch. A critical rule governed by JLS §14.5 prohibits local variable declaration statements as the immediate child statement of an unbraced if, else, while, or for loop:

boolean debug = true;

if (debug)
    int counter = 100; // COMPILE ERROR: variable declaration not allowed here

The rationale for this restriction is semantic: a local variable declared in an unbraced statement would fall out of scope immediately at the subsequent semicolon, making the variable completely unreachable and unusable. To declare a local variable inside an if branch, curly braces must create a block scope:

if (debug) {
    int counter = 100; // Legal: scoped within the block
    System.out.println(counter);
}

Similarly, omitting braces when multiple statements are intended results in subsequent statements executing unconditionally:

int x = 20;
if (x < 10)
    System.out.println("Small");
    System.out.println("Always executed!"); // Executes regardless of x

---

The Ternary Operator (? :)

The ternary operator provides a concise conditional expression with the following syntax:

booleanExpression ? expression1 : expression2

Core Operational Rules

1. Short-Circuit Evaluation: Exactly one of the two branch expressions is evaluated at runtime. If booleanExpression evaluates to true, expression1 is evaluated and expression2 is skipped entirely. If booleanExpression evaluates to false, expression1 is skipped and expression2 is evaluated. Side effects (such as post-increments or method invocations) located in the skipped branch do not take place.
2. Expression vs. Statement: The ternary construct is an expression, not a statement. It produces a value and must be used where a value is accepted (assigned to a variable, returned from a method, or passed as a method argument). It cannot exist as an isolated statement:

int score = 85;
// score > 50 ? System.out.println("Pass") : System.out.println("Fail"); // COMPILE ERROR: not a statement

// Legal usage:
String outcome = score > 50 ? "Pass" : "Fail";
System.out.println(score > 50 ? "Pass" : "Fail");

---

Type Unification and Unboxing Traps

The return type of a ternary expression is resolved at compile time through binary numeric promotion and reference type reconciliation. When the two operand expressions are of different types, the compiler determines a unified common type.

Numeric Type Promotion

If one operand is an int and the other is a double, the overall type of the ternary expression is promoted to double:

int a = 5;
double b = 10.5;
var result = true ? a : b; // result is inferred as double; value is 5.0

The NullPointerException Unboxing Hazard

When mixing primitive types with boxed wrapper objects in a ternary expression, Java automatically unboxes the wrapper to match the primitive type. If the boxed reference is null, this automatic unboxing triggers a runtime NullPointerException!

Integer defaultLimit = null;
boolean useDefault = false;

// Numeric unboxing occurs: 100 is int, defaultLimit is Integer.
// The ternary expression unboxes defaultLimit via defaultLimit.intValue()!
Number selectedLimit = useDefault ? defaultLimit : 100; // Returns 100 safely

// However, when the condition selects the null operand:
Number dangerousLimit = !useDefault ? defaultLimit : 100; 
// Throws java.lang.NullPointerException at runtime!

Even though dangerousLimit is declared as the abstract reference type java.lang.Number, the ternary operator inspects the types of both branches (Integer and int), recognizes that int requires unboxing of Integer, and evaluates defaultLimit.intValue(). Because defaultLimit is null, an unexpected NullPointerException occurs.

---

Nested Ternary Expressions and Evaluation Order

Ternary operators are right-associative. When multiple ternary operators are chained without parentheses:

int marks = 75;
String grade = marks >= 90 ? "A" : marks >= 75 ? "B" : marks >= 60 ? "C" : "F";

The expression parses from right to left as:

marks >= 90 ? "A" : (marks >= 75 ? "B" : (marks >= 60 ? "C" : "F"))

At runtime:

1. marks >= 90 is false.
2. The second expression marks >= 75 ? "B" : ... is evaluated.
3. marks >= 75 is true, yielding "B". The remaining expressions are skipped.

---

Decision Constructs Comparison