Forem: Sowmiya Ravikumar

Part 2 of Pattern Matching in Switch - Java

Sowmiya Ravikumar — Mon, 05 May 2025 16:07:38 +0000

This is the part 2 of the blog covering switch expressions in Java. If you haven't read part 1 yet, please give it a read here as it would cover some of the basic understanding of the switch expression and pattern matching in switch.

Switch Exhaustiveness

Java compiler doesn't force exhaustiveness in switch statements, whereas switch expression are expected to be exhaustive. What really is exhaustiveness? Exhaustiveness ensures that all possible cases are handled in a switch expression, either explicitly or with a default case. For example, When you use an enum type, switch must cover different values of the enum. This is not limited to enums, its applicable to all the types switch supports. Look at the below versions of code, former one with switch statement and the later with switch expressions.

This snippet of code compiles and runs fine, without any complaints for not having a case for GREEN.

enum Color { 
    RED, GREEN, BLUE
}

private static String switchForEnum(Color color) {
    String hexCode = null;
    switch (color) {
        case RED:
            System.out.println("Color is red..");
            hexCode = "#FF0000";
            break;
        case BLUE:
            System.out.println("Color is blue");
            hexCode = "#0000FF";
            break;
    }
    return hexCode;
}

Whereas below code will fail to compile with an error: the switch expression does not cover all possible input values. Switch expressions are expected to be exhaustive and the code that does not cover all possible cases, or lacks a Match-All case will result in compiler error. Exhaustiveness enforced in switch expressions because, unlike switch statements, switch expressions are expected to return a value or throw an exception. In the cases, where a case covering a particular value, or a match-all case is missing, switch wont be returning anything and it will cause runtime errors.

private static String switchExpForEnum(Color color) {
    return switch (color) {
        case RED -> {
            System.out.println("Color is red..");
            yield "#FF0000";
        }
        case BLUE -> {
            System.out.println("Color is blue");
            yield "#0000FF";
        }
        // Error can be fixed by uncommenting any of the below code blocks
        /*
        case GREEN -> {
            System.out.println("Color is green");
            yield "#00FF00";
        }
        */
        /*
        default -> {
            System.out.println("Color is unknown");
            yield "#FFFFFF";
        }*/
    };
}

The above code can be corrected by either adding a case for handling color GREEN or by adding a match-all case. Its better to add explicit case for color GREEN than a default, as default case would sweep issues under the rug if you may have to introduce more values to the enum in the future.

Have you noticed that there are no break statements, and there is new term yield?

switch statements are naturally fall-through, ie. without break statements between cases, execution would naturally continue to all the cases below the one that's matched until it encounters break or end of switch. This can cause for lot of troubles and switch expressions are designed to eliminate the fall-through behavior, so there is no need for break making the code concise and safe.
yield is a restricted identifier (not a keyword) introduced to return a value from the statement group matching a case in switch expression, similar to the keyword return used in switch statements.

Records patterns in switch

We have seen Typed Pattern in switch expression in the part 1 of the blog.
Records patterns allows pattern matching for record types and deconstruction of the record components directly in a switch expression. This feature is finalized in Java 21. Lets look at an example for the same.

sealed interface Quad permits Rectangle, Square, Kite {
    static double calculatePerimeter(Quad quad) {
        return switch(quad) {
            case Rectangle(double len, double bre) -> 2 * (len + bre);
            case Square(double s) -> 4 * s;
            case Kite(double shortSide, double longSide, _, _) -> 2 * (shortSide + longSide);
        };
    }
}

record Rectangle(double length, double breadth) implements Quad {}
record Square(double side) implements Quad {}
record Kite(double short_side, double long_side, double short_diag, double long_diag) implements Quad {}

Quad is a sealed interface which allows 3 records Rectangle, Square and Kite (classes with immutable data components) to implement its functionalities. Check the usage of the Record pattern in switch expression inside calculatePerimeter method.

Given switch expression takes a Quad type and its exhaustive, covering all the allowed record types. If you were to allow another record type for Quad, matching case arm should be added to the switch.
The labels used in the above cases are called Record Patterns. Observe that the components of the records are deconstructed into 1 or more pattern variables and are available directly to use.
Notice the usage of "_" in the last case. If there is any data component that you don't use in your logic, it need not be assigned to any variable. So, if you add an underscore, they are just ignored.

Nested record patterns

Above examples shows top level pattern matching. Records can be nested too ie.. one record can be a component of another record. Switch expressions allows nested pattern matching and nested deconstruction as well. Lets see it as an extension of the above code snippet.

sealed interface Quad permits Rectangle, Square, Kite, Parallelogram {
    static double calculatePerimeter(Quad quad) {
        return switch(quad) {
            // assuming all cases exists for Rectangle, Square and Kite from previous code
            case Parallelogram(Coordinate(double x1, double y1), Coordinate(double x2, double y2)) ->
                2 * (Math.hypot(x1, y1)  + Math.hypot(x2, y2));
        };
    }
}

record Coordinate(double x, double y) {}
record Parallelogram(Coordinate p1, Coordinate p2) implements Quad {}

Now, we have one more Quad variant - Parallelogram which has 2 nested components p1 and p2, instances of Coordinate record. In the switch expression, we added a case to perform top level matching of the Parallelogram type, and also deconstructs its nested Coordinate record components into their double types. These are nested records patterns.

We have seen how switch expressions makes the code more concise and functional, enhancing the safety and readability. Thank you reading up until this point. If you would like to read more such blogs or share your thoughts, write me at LinkedIn or Email.

References

Pattern Matching in Switch - Java

Sowmiya Ravikumar — Fri, 25 Apr 2025 15:32:57 +0000

Switch has come a long way from being a limited control structure to now supporting expressive features like switch expressions (finalized in Java 14) and pattern matching (finalized in Java 21).

Pain points

See how verbose and complex the code below looks. We are

null proofing
checking the type using instanceof
manually casting

This means that if you need to introduce more types in the future, you will end up with more if-else branches, manual checks and boilerplate code.

static void verboseDisplay(Object obj) {
    String result = "";
    if(Objects.nonNull(obj)) {
        if (obj instanceof String) {
            String str = (String) obj;
            int len = str.length();
            result = String.format("We have got string %s of length %d", str, len);
        } else if (obj instanceof Integer) {
            Integer num = (Integer) obj;
            result = String.format("We have got integer %d", num);
        } else {
            result = String.format("We have got %s of type %s", obj, obj.getClass().getName());
        }
    }
    System.out.println(result);
}

Doesn't this look better?

I have refactored the above code using switch expression and pattern matching.

static void cleanDisplay(Object obj) {
    String result  = switch(obj) {
        case null -> "";
        case String str -> String.format("We have got a string %s of length %d", str, str.length());
        case Integer num -> String.format("We have got an integer %d", num);
        default -> String.format("We have got %s of type %s", obj, obj.getClass().getName());
    };
    System.out.println(result);
}

We have moved away from

if-else branching
explicit null checks
type checks using instanceof
manual type casting
repetitive assignments inside case blocks

Let's break it down

We have used switch expression with arrow(->) and default case, instead of traditional switch with colon (:) and break statements. Since Java 21, null can be added as a valid case label.

💡Tip: Its a good practice to add the null case at the beginning before non-null cases for an early exit and avoiding NullPointerException. If you dont include null case, cleanDisplay(null) will cause NPE as before.

In the pattern label case String str , obj is the target object to evaluate, String str is the Type Pattern and str is the pattern variable. Here comes the power of pattern matching: the compiler checks if the target matches the type, if it is, it safely casts the target to the type and initializes the pattern variable with the data of the target. No explicit type checks and type casting needed.

Using Switch expressions, result can be returned directly from switch block, making code cleaner and functional.

Scope of the pattern variable

If the target matches the type pattern, then the pattern variable gets initialized and its scope lies within the block of the code which introduced it.

Consider this example

static void simpleScope(Object obj) {
    String result =  switch (obj) {
        case Integer i -> {
            System.out.println("I can be access inside this block");
            yield String.format("%d - Integer Type", i);
        }
        case String s1 when s1.length() <= 5 -> String.format("%s - String Type of length <= 5", s1);
        case String s2 -> String.format("%s - String Type of length > 5", s2);
        default -> "Unknown Type";
    };
    System.out.println(result);
}

If the type of obj is an Integer, the scope of the pattern variable i is valid within the block to right side of the arrow.
If the type of obj is String, scope of the pattern variable s1 is valid in the when clause as well as in statement to the right of the arrow.

Consider the below example for instanceof

static void scopeTest(Object obj) {
    if(!(obj instanceof String s)) {
        System.out.println("s cannot be accessed here");
        return;
    }
    System.out.printf("s can very well be accessed here %s", s);
}

If type of obj is String, pattern varaible s can be accessed anywhere inside the method. For other types, s is never initialized because the pattern dont't match.

Guarded pattern label

In this example, did you notice the second case label? Unlike the first case label with a type pattern, this one also has a when clause followed by a boolean expression. These type of case label is referred as Guarded pattern label.

It's a guard

If obj is of type String and the length of the string is lesser than or equal to 5, then the statement to the right of 2nd case label gets executed. Otherwise (if type of obj is String and boolean expression str.length() <= 5 evaluates to false), then the statement to the right of 3rd case label gets executed.

Switch now supports primitive types

⚠️ This is still a preview feature introduced in Java 23 and re-introduced with no change in Java 24. Switch supports String, enum, reference types and also some primitive types like char, byte, short and int, as well as their auto-boxed classes. However, as part of this preview feature long, float, double, and boolean primitive types are also now supported.

Look at this example

static void primitiveTypes(float fVal) {
    switch (fVal) {
        case 0f, 1f -> System.out.println("We have got a float 0 or 1");
        case float f -> System.out.printf("We have got a float %f%n", f);
    }
}

Here, switch accepts primitive type - float. 1st case matches constant float values and 2nd case matches any float values other than (0f or 1f).

💡Tip: Enable preview feature while running this code.

Unconditionally exact casting

If you would call primitiveTypes method with below signature, compiler would implicitly cast int to float.

int num = 1;
primitiveTypes(num);

Whereas, consider primitiveTypeInt method in which switch accepts int and you would call the method with float, 💥 compiler will throw error.

static void primitiveTypeInt(int fVal) {
    switch (fVal) {
        case 0, 1 -> System.out.println("We have got a float 0 or 1");
        case int f -> System.out.printf("We have got a float %d%n", f);
    }
}

primitiveTypeInt(1f);

Case dominance

In this example, if you swap the cases, case float f will dominate case 0f, 1f and compiler will throw error because case 2 is never reachable.

So, as a rule of thumb, follow this order:

Constant case labels
Guarded pattern labels
Non-guarded pattern labels

static void orderedCases(float fVal) {
    switch (fVal) {
        case 0f, 1f -> System.out.println("We have got a float 0 or 1");
        case float f when f <= 5 -> System.out.printf("We have got a float > 1 and <= 5: %f%n", f);
        case float f -> System.out.println("We have got a float > 5");

    }
}

We have covered some of the important features of switch introduced in recent Java releases. This is just part 1 of the blog, I will try to cover record patterns, top-level and nested patterns, switch exhaustiveness and much more in part 2. Thank you for reading up until this point. Let me know if you find it useful, that will keep me motivated to write more.

If you like to connect, or share your thoughts and views, feel free to drop a message at LinkedIn or Email