Switch Case in Java

The switch statement is an elegant alternative to a long else-if ladder when you compare one value against many constants. Since Java 14, the modern arrow switch form makes switch even more powerful — no fall-through, expression-based and supports returning values.

• Classic: switch(x) { case 1: …; break; default: …; }
• Arrow: switch(x) { case 1 -> …; default -> …; }
• Use break in classic switch to prevent fall-through.
• Switch on String, char, int, byte, short, enum.

Let's start with a hands-on example. The program below shows the core idea behind Switch Case in just a few lines of Java. Read it line by line and observe how Java executes each statement in order.

class Main
{
    public static void main(String args[])
    {
        int day = 3;

        switch (day)
        {
            case 1: System.out.println("Mon"); break;
            case 2: System.out.println("Tue"); break;
            case 3: System.out.println("Wed"); break;
            case 4: System.out.println("Thu"); break;
            case 5: System.out.println("Fri"); break;
            default: System.out.println("Weekend");
        }
    }
}

The following examples progress from simple to more practical patterns. Try each in your IDE, change the inputs and observe the output. This is the fastest way to internalize the concept.

class Main
{
    public static void main(String args[])
    {
        String color = "red";

        switch (color)
        {
            case "red":   System.out.println("STOP"); break;
            case "green": System.out.println("GO");   break;
            default:      System.out.println("WAIT");
        }
    }
}

class Main
{
    public static void main(String args[])
    {
        int n = 2;

        String result = switch (n)
        {
            case 1 -> "One";
            case 2 -> "Two";
            case 3 -> "Three";
            default -> "Other";
        };

        System.out.println(result);
    }
}

class Main
{
    public static void main(String args[])
    {
        int day = 6;

        String type = switch (day)
        {
            case 1,2,3,4,5 -> "Weekday";
            case 6,7       -> "Weekend";
            default        -> "Invalid";
        };

        System.out.println(type);
    }
}

class Main
{
    public static void main(String args[])
    {
        int x = 2;

        switch (x)
        {
            case 1:
            case 2:
            case 3:
                System.out.println("Small");
                break;
            default:
                System.out.println("Big");
        }
    }
}

enum Day { MON, TUE, WED }

class Main
{
    public static void main(String args[])
    {
        Day d = Day.WED;

        switch (d)
        {
            case MON -> System.out.println("Monday");
            case TUE -> System.out.println("Tuesday");
            case WED -> System.out.println("Wednesday");
        }
    }
}

• Always include a default case for robustness.
• Forgetting break in classic switch causes fall-through bugs.
• Arrow switch (Java 14+) does not fall through.
• Switch case labels must be constants known at compile time.
• Switch expression must end with a semicolon when assigned.

Reading is not enough — practice solidifies knowledge. Try every question below in your own editor before peeking at any solution.

• Q1. Print month name from month number using switch.
• Q2. Convert grade letter to feedback using switch.
• Q3. Build a calculator with switch on +, -, *, / characters.
• Q4. Use arrow switch to map traffic light color to action.
• Q5. Rewrite an else-if ladder as a switch.

These are the most common questions asked in Java interviews on this topic. Memorize the concept, not just the answer — interviewers often follow up with edge cases.

Even experienced developers slip on the same pitfalls. Watch out for these classic mistakes while working with Switch Case in Java:

• Forgetting the semicolon ; at the end of statements while using Switch Case.
• Mixing up similar method names — read Java docs before using new APIs related to Switch Case.
• Ignoring compiler warnings — they often hint at bugs that will appear later in production.
• Hard-coding values that should come from configuration files or environment variables.
• Not handling edge cases: empty inputs, very large inputs, negative numbers and null references.
• Skipping unit tests — small tests prevent big regressions, especially around control flow.