if…else

In short: Extends the simple if statement with an alternative branch that runs when the condition is false.

In more detail: Several conditions can be chained with else if (see else…if), and at the end a closing else (with no condition of its own) catches all remaining cases. For simple value decisions, Java additionally offers the ternary operator as shorthand: int x = condition ? a : b;.

if (grade <= 4) {
    System.out.println("Passed");
} else {
    System.out.println("Failed");
}

In Depth

int grade = 5;
if (grade <= 4) {
    System.out.println("Passed");
} else {
    System.out.println("Failed");
}
 
// Ternary operator - compact alternative for simple value decisions
String result = (grade <= 4) ? "Passed" : "Failed";
 
// Nested (caution: quickly gets confusing)
String category = (grade <= 2) ? "Good" : (grade <= 4) ? "Passed" : "Failed";

The ternary operator (condition ? valueIfTrue : valueIfFalse) is syntactically an EXPRESSION, not a statement — it directly returns a value and can therefore, for example, be assigned directly to a variable or passed as a method argument, which isn’t easily possible with a full if...else block. For simple yes/no value decisions it’s more compact and considered more readable by many; but with more than one nested condition it quickly tips into the opposite, and a spelled-out if...else or switch statement stays clearer.

The “dangling else” problem

Without curly braces, it can become ambiguous WHICH if an else belongs to — Java resolves this (like most C-like languages) by having an else always belong to the NEAREST open if, which often doesn’t match intuition:

if (a > 0)
    if (b > 0)
        System.out.println("both positive");
else // belongs to the inner if(b > 0), NOT the outer if(a > 0)!
    System.out.println("b not positive");

For a <= 0, NOTHING AT ALL is printed here, even though the indentation suggests the else belongs to the outer if. This is exactly why it’s considered best practice in practically every Java style guide to always use curly braces for nested conditions, even if the block only contains one line — this makes the association unambiguous and equally readable for the compiler AND for humans.

if with no else — and when it’s missing

An if with no else at all is completely normal when nothing should happen in the negative case. A common beginner mistake, however, is FORGETTING an else where an alternative would actually be needed — e.g. a validation that silently continues on invalid input instead of reporting an error. Checking whether ALL possible cases are really covered (including the “unlikely” one) is one of the standard debugging questions for unexpected program behaviour.

Pattern matching for instanceof

Since Java 16, an if condition with instanceof can be combined directly with a type variable that’s automatically usable in the if branch, with no manual cast:

Object o = "Some text";
if (o instanceof String s) { // s is automatically of type String from here on
    System.out.println(s.length());
} else {
    System.out.println("Not a String");
}

Before Java 16, you still had to cast manually after an instanceof check (String s = (String) o;) — an extra line that was easy to forget or write with the wrong type.

See also: if Statement, else…if