Java if-else — Silent Login Failure from == String Compare

Every useful program in the world makes decisions. Your banking app decides whether your PIN is correct. A game decides whether your health dropped to zero. A weather app decides whether to show a sun or a rain cloud. None of that is possible without conditional logic — and in Java, the if-else statement is the very first and most fundamental tool for writing code that thinks. Without it, your program would just be a straight line of instructions with no ability to react to the real world.

Early programming relied heavily on goto jumps for branching — an approach so error-prone it gave rise to the term 'spaghetti code'. Structured if-else brought clarity and readability to conditional logic. It gave programmers a clean, readable structure: state your condition plainly, define what happens when it's true, and define a fallback for when it isn't. It makes code read almost like plain English, which is a superpower when you're working on a team or revisiting your own code six months later.

By the time you finish this article, you'll be able to write Java programs that make real decisions — checking ages, comparing scores, validating inputs, and chaining multiple conditions together. You'll also know the exact mistakes beginners always make (and exactly how to avoid them), so you can write cleaner code from day one.

The Simple if Statement — Teaching Java to Ask One Question

Before we add the 'else', let's nail the simplest form: a plain if statement. Think of it as a bouncer at a club door. The bouncer has one job: check if you're old enough. If yes, you're in. If no — nothing happens, you just walk away. The bouncer doesn't chase you down to explain anything. That's exactly how a plain if works in Java: if the condition is true, run the block of code; if it's false, skip it entirely and move on.

The condition inside the parentheses must always produce either true or false — Java calls this a boolean expression. You can compare numbers with operators like > (greater than), < (less than), >= (greater than or equal to), <= (less than or equal to), == (equal to), and != (not equal to). Notice that equality uses double equals (==), not a single equals sign — that single one is for assigning values, and mixing them up is one of the most common beginner bugs. Java actually catches the single-equals mistake at compile time and refuses to build, which saves you from a class of silent bugs that plague other languages.

The curly braces {} wrap the block of code that only runs when the condition is true. Even if you only have one line inside, get into the habit of always using curly braces. Skipping them is a trap we'll cover in detail later — it's responsible for more production incidents than most developers realise.

Here is a quick reference for the boolean operators you will use constantly inside if conditions:

== equal to (values match) != not equal to (values differ) > greater than < less than >= greater than or equal to <= less than or equal to

These operators always return either true or false, which is exactly what the if statement expects.

public class ClubBouncer {
    public static void main(String[] args) {

        int visitorAge = 20; // The age of the person at the door

        // The 'if' keyword introduces our condition.
        // Java evaluates the expression inside the parentheses.
        // If it's true, the code inside the curly braces runs.
        // If it's false, Java skips this entire block.
        if (visitorAge >= 18) {
            System.out.println("Welcome in! Enjoy your evening.");
        }

        // This line always runs — it's outside the if block.
        System.out.println("Bouncer check complete.");
    }
}

The if-else Statement — Giving Java a Plan B

A plain if is useful, but most real situations need a response either way. If the payment goes through, show a receipt — else, show an error. If the password matches, log the user in — else, show 'wrong password'. This is where else comes in: it's Java's plan B, the fallback that runs when the if condition is false.

Think of it like a coin flip. You call heads — if it lands on heads, you win; else, you lose. One of the two outcomes always happens. That's the guarantee of if-else: exactly one branch will execute, never both, never neither.

The structure is clean and symmetrical. You write your if block first, then immediately attach the else block. There's no second condition on else — it doesn't need one. It's the catch-all. The moment Java sees the if condition is false, it jumps straight into the else block, runs it, then continues on with the rest of the program.

Notice in the code below how we use meaningful variable names like userPassword and correctPassword instead of vague placeholders — this makes the logic read almost like a sentence. You will also see that we use .equals() to compare Strings, not ==. This is non-negotiable in Java and the next callout explains exactly why.

public class LoginCheck {
    public static void main(String[] args) {

        String correctPassword = "OpenSesame123"; // The real password stored in our system
        String userPassword = "WrongGuess";       // What the user typed in

        // The == operator does NOT work correctly for comparing Strings in Java.
        // == checks whether two variables point to the same object in memory.
        // Two strings can contain identical characters and still be different objects.
        // Always use .equals() to compare String content — every single time.
        // Placing the known value on the left ("constant".equals(variable)) is null-safe:
        // if userPassword is null, this returns false cleanly instead of throwing.
        if (correctPassword.equals(userPassword)) {
            // This block runs ONLY if the passwords match
            System.out.println("Login successful! Welcome back.");
            System.out.println("Redirecting to your dashboard...");
        } else {
            // This block runs ONLY if the passwords do NOT match
            System.out.println("Incorrect password. Please try again.");
            System.out.println("Tip: Passwords are case-sensitive.");
        }

        // Java always reaches this line — it's after the entire if-else
        System.out.println("Login attempt logged.");
    }
}

else-if Chains — Handling More Than Two Possibilities

Real life rarely offers just two options. Exam grades aren't just pass/fail — they're A, B, C, D, or F. A delivery isn't just 'arrived' or 'not arrived' — it could be 'processing', 'shipped', 'out for delivery', or 'delivered'. When you have three or more possible outcomes, you chain conditions together using else-if.

Here's how it works: Java checks the first if condition. If it's false, it moves to the first else-if and checks that condition. If that's also false, it checks the next else-if, and so on. The moment any condition is true, Java runs that block and skips everything else in the chain — this is called short-circuiting, and it's important for both correctness and performance. The final plain else at the end is optional — it acts as your ultimate catch-all for anything that didn't match any condition above.

Order matters enormously here. Java checks conditions from top to bottom and stops at the first match. If you put a broad condition above a narrow one, the narrow one might never run. For example, checking if a score is >= 50 before checking if it's >= 90 means anyone scoring 95 gets caught by the first condition and never reaches the 'A grade' check. Always order from most specific to least specific.

A useful discipline before writing an else-if chain: list your conditions on paper from narrowest to broadest, then code them in that order. Then test the boundary values — exactly 90, exactly 75, exactly 60, exactly 40, one above each, one below each. Boundary testing catches ordering bugs immediately.

You can chain as many else-if blocks as you need, but if you find yourself writing more than four or five, a switch statement is often cleaner — something covered later in this article.

public class ExamGradeCalculator {
    public static void main(String[] args) {

        int examScore = 73; // The student's score out of 100

        // Java checks each condition in order, top to bottom.
        // The FIRST condition that evaluates to true wins.
        // All remaining else-if blocks are skipped once a match is found.
        // Conditions are ordered most restrictive to least restrictive — critical for correctness.

        if (examScore >= 90) {
            // Score is 90 or above — most specific range, checked first
            System.out.println("Grade: A — Outstanding work!");

        } else if (examScore >= 75) {
            // Score is 75-89 — only reached if the first condition was false
            System.out.println("Grade: B — Great effort!");

        } else if (examScore >= 60) {
            // Score is 60-74 — our student's score of 73 lands here
            System.out.println("Grade: C — Solid pass, keep pushing.");

        } else if (examScore >= 40) {
            // Score is 40-59
            System.out.println("Grade: D — You passed, but review the material.");

        } else {
            // Score is below 40 — catch-all else handles everything that didn't match above
            System.out.println("Grade: F — Don't give up, resits are available.");
        }

        System.out.println("Your score: " + examScore + "/100");
    }
}

Nested if-else — Making Decisions Inside Decisions

Sometimes one decision depends on another. Think about an online store checkout: first, does the user have items in the cart? If yes, then check — are they logged in? If yes, then check — do they have enough funds? Each question only makes sense after the previous one is answered. This layered logic is called nesting — putting an if-else inside another if-else.

Nesting is completely valid and very common, but it carries a real cost: the deeper you go, the harder the code is to read and the easier it is to misplace an else. At two levels of nesting it's usually fine. At three levels you should pause and ask whether the logic can be simplified. Beyond three levels, extract the inner logic into a separate named method — not for performance, but for your sanity and for everyone who maintains this code after you.

For now, understand that every if-else block can contain another complete if-else block inside it. The inner condition only gets evaluated if the outer condition was true first. This lets you build decision trees while keeping each decision explicit and traceable.

Indentation is critical here. Proper indentation makes the nesting visually obvious — you can see which else belongs to which if without counting braces. Your IDE handles this automatically, but always review it manually when things get complex. A misaligned else is one of the hardest bugs to spot in a code review because the logic looks correct until you count the braces.

public class OnlineCheckout {
    public static void main(String[] args) {

        boolean hasItemsInCart = true;  // Does the user have products in their basket?
        boolean isLoggedIn = true;       // Is the user authenticated?
        double accountBalance = 35.00;   // User's available credit
        double orderTotal = 28.50;       // Total cost of the order

        // Outer if: first gate — no point checking anything else if the cart is empty
        if (hasItemsInCart) {
            System.out.println("Cart is not empty. Proceeding to checkout...");

            // Inner if: second gate — only reached if cart has items
            if (isLoggedIn) {
                System.out.println("User is authenticated. Checking balance...");

                // Innermost if: third gate — only reached if logged in
                if (accountBalance >= orderTotal) {
                    double remainingBalance = accountBalance - orderTotal;
                    System.out.println("Payment successful! Order confirmed.");
                    // String.format ensures currency always displays with two decimal places
                    System.out.println("Remaining balance: £" + String.format("%.2f", remainingBalance));
                } else {
                    System.out.println("Insufficient funds. Please top up your account.");
                }

            } else {
                System.out.println("Please log in to continue with your purchase.");
            }

        } else {
            System.out.println("Your cart is empty. Add some items first!");
        }
    }
}

Compound Conditions — Combining Multiple Booleans with &&, ||, !

Real-world conditions are rarely a single comparison. 'If the user is an admin AND the request comes from the internal network, grant access.' 'If the score is less than 40 OR the student didn't submit the assignment, mark as fail.' These combine multiple boolean expressions using logical operators: && (AND), || (OR), and ! (NOT).

Combine any number of conditions into one if statement. The && requires both sides to be true for the whole expression to be true. The || requires at least one side to be true. The ! flips a boolean from true to false — useful for making negative conditions read more clearly.

Short-circuit evaluation is the behaviour you need to understand deeply: Java stops evaluating as soon as it knows the final result. With &&, if the first condition is false, the second is never evaluated — the whole expression must be false regardless. With ||, if the first condition is true, the second is skipped — the whole expression must be true regardless. This is not just an optimisation. It determines whether the second condition's code runs at all.

That matters in two important situations. First, null safety: if (object != null && object.isValid()) is safe because if object is null, the && short-circuits and isValid() is never called. Reverse the order and you get a NullPointerException every time object is null. Second, side effects: if the second condition calls a method that increments a counter, logs something, or updates state, that method will not execute when short-circuiting prevents it from being reached. This is a genuinely subtle source of production bugs.

Always use parentheses to group compound conditions explicitly. Java has operator precedence rules — ! binds tightest, then &&, then || — but relying on that in code review is a recipe for misreading. Parentheses make intent unambiguous and take zero extra runtime cost.

Boolean operator quick reference:

&& AND — both conditions must be true || OR — at least one condition must be true ! NOT — inverts true to false and false to true && short-circuits on first false (left to right) || short-circuits on first true (left to right)

public class AdminAccess {
    public static void main(String[] args) {

        boolean isAdmin = true;
        String userIp = "10.0.5.12"; // User's IP address

        // && (AND): BOTH conditions must be true for this branch to execute.
        // Short-circuit: if isAdmin is false, userIp.startsWith() is never called.
        if (isAdmin && userIp.startsWith("10.")) {
            System.out.println("Full admin access granted.");

        } else if (isAdmin || userIp.startsWith("10.")) {
            // || (OR): At least ONE condition must be true.
            // Short-circuit: if isAdmin is true, startsWith() is never called.
            System.out.println("Restricted access: one condition met but not both.");

        } else {
            System.out.println("Access denied.");
        }

        // ! (NOT): Inverts the boolean — reads clearly as 'if user is not blocked'
        boolean isBlocked = false;
        if (!isBlocked) {
            System.out.println("User is not blocked. Proceed.");
        }

        // Null-safe pattern using && short-circuit — always put the null check first
        String userInput = null;
        if (userInput != null && userInput.startsWith("admin")) {
            System.out.println("Admin command detected.");
        } else {
            // userInput.startsWith() was never called because short-circuit stopped at null check
            System.out.println("Input is null or not an admin command — handled safely.");
        }
    }
}

if-else vs Ternary Operator: When to Use a Compact One-Liner

Java's ternary operator ( ? : ) is a compact alternative to if-else for simple value assignments. Instead of writing four lines of if-else to assign a single variable, you can express it in one line:

String result = (score >= 60) ? "Pass" : "Fail";

That is readable, clean, and idiomatic Java. But the ternary is a precision tool, not a general-purpose replacement. It has one job: evaluate a condition and return one of two values. Use it only when the condition is simple, both branches are single expressions, and the result is being assigned to a variable.

Nesting ternaries is a readability disaster. The moment you write a ? b ? c : d : e, you have created something that requires a second read to understand and a third read to confidently modify. That is not clever — that is a maintenance burden. If you need more than one level, use if-else.

The ternary is an expression, not a statement. This has two practical consequences. First, you cannot use it for void method calls — you can only use it where a value is expected. If both branches call methods that return nothing, use if-else. Second, the ternary has the same short-circuit behaviour as && and || — the branch not taken is never evaluated. This makes it useful for null-safe default values: String name = (user != null) ? user.getName() : "Guest";

One non-obvious pitfall: mixing a wrapper type and a primitive in ternary branches triggers unboxing. If one branch returns an Integer and the other returns an int, Java unboxes the Integer to match types. If that Integer is null, you get a NullPointerException at runtime — not at compile time. The fix is to ensure both branches return the same type explicitly.

public class PassFail {
    public static void main(String[] args) {

        int score = 73;

        // Ternary: condition ? valueIfTrue : valueIfFalse
        // Clean and readable for simple single-value assignments.
        String result = (score >= 60) ? "Pass" : "Fail";
        System.out.println("Result: " + result);

        // Null-safe default value — a natural fit for the ternary.
        // The branch not taken is never evaluated, so getName() is only called when user is not null.
        String userInput = null;
        String safeInput = (userInput != null) ? userInput : "default";
        System.out.println("Safe input: " + safeInput);

        // AVOID: Nested ternaries — technically valid Java, but almost unreadable.
        // BAD:  String grade = (score >= 90) ? "A" : (score >= 75) ? "B" : "C";
        // Use an else-if chain instead — it is explicit and debuggable.

        // AVOID: Ternary with Integer/int mix — unboxing NPE risk.
        // Integer a = null;
        // int b = (score > 50) ? a : 0;  // Throws NullPointerException at runtime.
        // Java promotes the int literal 0 to require an int, which forces unboxing of 'a'.
        // Since 'a' is null, unboxing throws immediately. Fix: ensure both branches return the same type.
    }
}

if-else vs switch: Choosing the Right Tool for Multiple Exact Matches

When you are checking one variable against many exact values, switch is often a better fit than a long else-if chain. The else-if approach works, but it repeats the same variable name on every line and buries the list of values inside condition syntax. Switch makes the intent explicit: 'I am selecting one outcome based on the value of this single variable.'

Traditional switch (pre-Java 14) has one serious hazard: fall-through. Without a break statement at the end of each case, execution falls through to the next case and runs it regardless. This was occasionally used intentionally for grouping, but far more often it was a forgotten break that caused silent wrong behaviour.

Modern switch expressions (Java 14, standardised in Java 16) solve this completely with arrow syntax. Each case uses -> instead of :, executes exactly one expression, and returns a value. There is no fall-through, no break needed, and the compiler enforces exhaustiveness — it will tell you if you have missed a case for an enum. This is the version you should write in any codebase on Java 14 or higher.

The decision of when to use switch versus if-else comes down to what you are comparing: - Ranges and complex boolean logic: use if-else. Switch cannot express 'score >= 60 and score < 75'. - One variable against many exact constants: use switch, especially modern switch expressions. - Checking conditions that involve multiple different variables: use if-else. - Matching on an enum where exhaustiveness matters: switch expressions with the compiler enforcing coverage.

Note on null: both traditional and modern switch throw a NullPointerException if the switched variable is null. This is not a difference between switch and if-else — if-else with == null would handle it, but switch does not. Always null-check your variable before passing it to a switch.

public class SwitchVsIfElse {
    public static void main(String[] args) {

        int errorCode = 404;

        // Approach 1: else-if chain
        // Works fine, but repeats 'errorCode ==' on every line.
        String errorMessageIfElse;
        if (errorCode == 400) {
            errorMessageIfElse = "Bad Request";
        } else if (errorCode == 401) {
            errorMessageIfElse = "Unauthorized";
        } else if (errorCode == 403) {
            errorMessageIfElse = "Forbidden";
        } else if (errorCode == 404) {
            errorMessageIfElse = "Not Found";
        } else if (errorCode == 500) {
            errorMessageIfElse = "Internal Server Error";
        } else {
            errorMessageIfElse = "Unknown Error";
        }
        System.out.println("else-if result: " + errorMessageIfElse);

        // Approach 2: Modern switch expression (Java 14+, standardised Java 16)
        // Arrow syntax eliminates fall-through entirely — no break needed.
        // The compiler enforces that all cases return a value.
        String errorMessageSwitch = switch (errorCode) {
            case 400 -> "Bad Request";
            case 401 -> "Unauthorized";
            case 403 -> "Forbidden";
            case 404 -> "Not Found";
            case 500 -> "Internal Server Error";
            default  -> "Unknown Error";
        };
        System.out.println("switch result: " + errorMessageSwitch);

        // CAUTION: both switch forms throw NullPointerException if the variable is null.
        // Always null-check before switching on a String, Integer, or enum.
    }
}