Java switch Statement: Case-Based Program Flow Explained

Here is the problem a switch solves. To pick an action based on a day number, an if...else if ladder looks like this.

final int MONDAY = 1;
final int TUESDAY = 2;
final int WEDNESDAY = 3;
String type;
if (day == MONDAY) {
    type = "Start of week";
} else if (day == TUESDAY) {
    type = "Mid week";
} else if (day == WEDNESDAY) {
    type = "Mid week";
} else {
    type = "Other";
}

That works, but notice how hard it is to scan. Every option is wrapped in a condition, so the reader has to mentally strip away the if (day == noise to see the list of options. A switch shows the options plainly.

String type = switch (day) {
    case MONDAY -> "Start of week";
    case TUESDAY, WEDNESDAY -> "Mid week";
    default -> "Other";
};

Now the options are immediately visible, and the whole thing is three lines. That readability is the entire reason to prefer a switch once you have more than a few options.

If you have not read the two-way and multi-way versions yet, they are on our if...else page and our if...else if ladder page.

The older form uses a colon after each case and relies on break to stop.

final int MONDAY = 1;
final int TUESDAY = 2;
int day = MONDAY;
switch (day) {
    case MONDAY: System.out.println("Start of week");
    break;
    case TUESDAY: System.out.println("Mid week");
    break;
    default: System.out.println("Other day");
}

Remove the break from the MONDAY case and something surprising happens.

switch (day) {
    case MONDAY: System.out.println("Start of week");
    // no break here
    case TUESDAY: System.out.println("Mid week");
    break;
    default: System.out.println("Other day");
}

With day set to MONDAY, this prints both lines. That is fall-through: when a case ends without a break, Java does not stop, it simply carries on executing the next case body from the top.

Fall-through is not always a mistake. Grouping related cases is a legitimate use, and it is the reason the feature exists. Here the intent is deliberate, so no break is wanted between them.

switch (dayOfWeek) {
    case MONDAY: case TUESDAY: case WEDNESDAY: case THURSDAY: case FRIDAY: System.out.println("Weekday");
    break;
    case SATURDAY: case SUNDAY: System.out.println("Weekend");
    break;
    default: System.out.println("Invalid day");
}

Here the stacked cases mean "any of these values, run this one body". If a break appeared between MONDAY and TUESDAY, Monday would fall into Tuesday body, which is not what the code means. Read stacked cases as a single group, not as separate blocks.

From Java 14 onwards you can use -> instead of a colon. This single change removes three problems at once.

Here is the same day logic in the modern style.

String type = switch (day) {
    case MONDAY -> "Start of week";
    case TUESDAY, WEDNESDAY -> "Mid week";
    case 6, 7 -> "Weekend";
    default -> "Other day";
};

Read that as an expression: switch on day, and the result is a String that gets stored in type. Because it is an expression, you can also return it directly, use it in a System.out.println, or pass it to a method.

One arrow plus one expression is not always enough. When a case needs more than a single statement, use yield to supply the value, or use the block form.

// yield form, when a case needs to compute something first
int bonus = switch (level) {
    case "gold" -> 500;
    case "silver" -> {
        int base = 200;
        yield base * 2;
        // yield supplies the value for this case
    } default -> 0;
};

For running several statements and then not producing a value, the arrow form handles it directly, because a plain statement switch does not need to yield.

switch (level) {
    case "gold" -> {
        sendGift();
        announceWinner();
    } case "silver" -> sendSmallGift();
    default -> sendNothing();
}

The rule to remember: if the switch produces a value, every path must produce one, and yield is how a multi-statement case says so. If the switch only performs actions, there is no value to supply and no yield anywhere.

Here is a genuinely valuable modern feature. When you switch over an enum or a sealed type, the compiler checks that you have handled everything, and refuses to compile if you have not.

enum Status {
    PENDING, APPROVED, REJECTED
}String label = switch (status) {
    case PENDING -> "Waiting for review";
    case APPROVED -> "Accepted";
    case REJECTED -> "Declined";
    // no default needed: the compiler proves all three are covered
};

Now imagine someone adds CANCELLED to the enum next month. The old code would still compile with an if-chain, and CANCELLED would quietly fall into whatever came last, usually wrong. With a switch expression over an enum, the build fails until you handle it. The compiler turns a silent production bug into a build error you find in seconds.

The same guarantee works for sealed classes, which is the other way to get a closed set of possibilities. Both ideas are covered on our Java enums page and our modern Java features page.

Three of those surprise people. long is not allowed in any switch form, which catches people who reach for it to store an ID. boolean is not allowed either, and this one is by design rather than an oversight: a boolean has only two values, so an if says it better and a switch would just be noise.

For the boolean case, write this instead.

// Clearer than any switch could be
if (isEnabled) {
    start();
} else {
    stop();
}

One more trap worth naming. A String switch works, but the same identity rule as everywhere else in Java applies to the case labels, so a case must be a compile-time constant. You cannot switch on a variable, and you cannot write default twice.

That third and fourth rows are worth contrasting. In the classic statement, a missing default is a quiet failure. In a switch expression, forgetting to produce a value on one path is a compile error. Modern Java deliberately moved these mistakes from runtime to compile time, which is why the newer form is safer.

Here is a small program that shows a classic statement, a modern expression, and an enum switch with exhaustiveness.

// A modern switch expression over an enum needs no default,
// because the compiler proves every constant is covered.
String badge = switch (status) {
    case PENDING -> "GRAY";
    case APPROVED -> "GREEN";
    case REJECTED -> "RED";
};

That is the form to reach for in real code. It is short, it cannot fall through, and adding a new Status constant breaks the build until you deal with it.

Frequently Asked Questions

What is fall-through and is it ever useful?

Fall-through is when a case without a break continues into the next case body. It is almost always a bug, but it is genuinely useful for grouping several values onto one shared body, which is what stacked case lines achieve.

Should I still learn the classic switch?

Yes, you should recognise it because you will meet it everywhere in older codebases, and it comes up constantly in interviews. Just write the arrow form in new code, since it removes an entire category of bug.

Why can I not switch on a boolean?

By design, not by accident. A boolean has exactly two values, so an if expresses it far more clearly, and a switch would add structure without adding meaning.

Why can I not switch on a long?

It has never been allowed in any version of Java. If you need to branch on a large number, store an int alongside it and switch on that, or use an if chain.

Is default required?

In a classic statement you should always include one. In a modern switch over an enum or a sealed type, the compiler can prove you covered everything, so default becomes optional, and adding one can even be a warning since it may be unreachable.

Can I use a variable as a case value?

No. Case labels must be compile-time constants, literals, enum constants, or in the modern form, patterns. A variable is not known until run time, so it cannot be a case label.

When should I still choose an if ladder instead?

When your conditions are ranges rather than exact values, such as checking whether a number is above a threshold, or when you are combining several different variables. A switch matches one value against exact options, so an if chain is the right tool for range and compound logic.

Does a switch make my program faster?

Not meaningfully. The JVM compiles a switch into a jump table or a lookup, which is efficient, but a well-written if chain over a handful of conditions is already fast enough that you will never measure a difference. Choose a switch for readability and safety, not speed.