How Do if-else and switch Differ in Java?

Both choose between alternatives, but they suit different shapes of decision. An if-else chain is a general conditional: it evaluates boolean expressions, supports ranges and compound conditions, and nests as deeply as you like. A switch dispatches on a single value against a fixed list of constants, which makes it easier to read when you have six or more mutually exclusive cases.

Three practical differences. First, a switch on a String or an enum compares against known constants using equals semantics, so you cannot write a range or a compound condition inside a case label; for that you fall back to if-else. Second, a switch expression must be exhaustive, which turns a whole class of missing-branch bugs into compile errors. Third, an if-else chain silently falls through to the end when no branch matches, while an arrow-labelled switch case does nothing at all unless you provide a default.

The switch expression is the better default for value selection. It produces a value instead of assigning into a variable in every branch, and the arrow form removes fall-through entirely, because each case ends at the arrow rather than at the next label.

Where if-else still wins: conditions that are not equality tests, ranges such as score >= 90, and any decision with fewer than three branches. Switching on two or three values is usually clearer as an if-else than as a switch with a single case.

A switch statement is a control-flow construct: it picks a branch and executes statements. A switch expression computes a value. The expression form is the reason you can write String label = switch (code) { ... }; and have the compiler prove the expression is exhaustive.

The arrow label, case VALUE ->, changes two things. The branch no longer falls through into the next case, so you do not need a break, and several values can share one branch using commas, as in case 1, 7 ->. The colon form, case VALUE:, keeps the old fall-through behaviour, which is occasionally what you want but is far more often a bug.

public class Main {
    public static void main(String[] args) {
        int day = 3;
        String name = switch (day) {
            case 1, 7 -> "weekend";
            case 2, 3, 4, 5, 6 -> "weekday";
            default -> "unknown";
        };
        System.out.println("day " + day + " -> " + name);

        // The classic colon form still falls through unless you break.
        int count = 2;
        switch (count) {
            case 1:
                System.out.println("one");
            case 2:
                System.out.println("two");
            case 3:
                System.out.println("three");
                break;
            default:
                System.out.println("other");
        }
    }
}

One more switch expression detail worth knowing: when a branch needs more than a single expression, you use the yield keyword to supply the value, and yield exits the switch immediately. The colon form of a switch expression uses yield too, while the arrow form allows a full block that ends in yield. And in a switch expression over an enum, covering every constant without a default branch is enough — the compiler treats that as exhaustive and will refuse to compile if a new constant is later added to the enum without updating the switch, which is exactly the safety you want.

The old colon form of switch allows fall-through: when a case body ends without a break, execution continues into the statements of the next case. That was occasionally useful for grouping, but it was also a standing invitation to bugs. A missing break in the middle of a long switch silently runs the wrong code, and because the code still compiles and often produces a plausible result, the defect survives review and reaches production.

The arrow form makes fall-through impossible. Each case X -> branch ends at the arrow; there is no way for one branch to continue into the next unless you explicitly say so. That is what makes it safe to use as an expression, because an expression must produce exactly one value and must not run a block of code twice or in the wrong order.

public class Main {

    enum Status { NEW, RUNNING, DONE }

    public static void main(String[] args) {
        Status status = Status.RUNNING;

        // Every constant is covered, so no default is needed.
        // Add a constant to the enum and this stops compiling - on purpose.
        String label = switch (status) {
            case NEW -> "queued";
            case RUNNING -> "in progress";
            case DONE -> "finished";
        };
        System.out.println("label = " + label);

        // The same decision written as a statement, grouped with a fall-through.
        String classic;
        switch (status) {
            case NEW:
                classic = "queued";
                break;
            case RUNNING:
            case DONE:
                classic = "finished work";
                break;
            default:
                classic = "unknown";
        }
        System.out.println("classic = " + classic);
    }
}

The exhaustiveness rule is the bigger long-term win. A switch expression over an enum must cover every constant or provide a default, so when someone adds a new constant to the enum the compiler points at every switch that needs updating. Combined with arrow labels, that turns a class of runtime defects into compile-time errors, which is the main reason the Java team pushed switch expressions so hard.