{"id":409395,"date":"2024-01-30T07:04:43","date_gmt":"2024-01-30T06:04:43","guid":{"rendered":"https:\/\/blog.jetbrains.com\/?post_type=idea&p=409395"},"modified":"2024-01-30T15:34:13","modified_gmt":"2024-01-30T14:34:13","slug":"evolution-of-the-switch-construct-in-java-why-should-you-care","status":"publish","type":"idea","link":"https:\/\/blog.jetbrains.com\/idea\/2024\/01\/evolution-of-the-switch-construct-in-java-why-should-you-care\/","title":{"rendered":"Evolution of the Switch Construct in Java\u2014Why Should you Care?"},"content":{"rendered":"\n

Even though defining conditions in code is one of the programming basics, developers didn\u2019t use the old<\/em> switch<\/code> statements often because this feature was quite constrained in its capabilities. This is not the case anymore. With the addition of switch expressions and Pattern Matching, the switch construct has evolved a lot\u2014it can return values, switch over multiple types, compare objects and not just constants in case labels, and much more. It can replace long if-else<\/code> constructs and older switch statements with concise code, for use cases that you might not know about. It has fewer bugs, is easier to read, write, and understand, and is a charm to work with.\u00a0<\/p>\n\n\n\n

Don\u2019t worry if all these new features overwhelm you. IntelliJ IDEA can help you get started with using the modern switch construct. It can detect if-else code\/ old switch style that could be replaced with the new switch, even if you don\u2019t know anything about its syntax or usage. IntelliJ IDEA can also prompt you to use the switch in the correct or improved way.<\/p>\n\n\n\n

In this blog post, I\u2019ll cover all these changes using hands-on coding examples to highlight their benefits. I\u2019ll also address a few of the frequently asked questions by developers, such as, why does it seem that the switch has been changing over a long time, why, and how.\u00a0<\/p>\n\n\n\n

1. Understanding the Bigger Picture<\/h2>\n\n\n\n

Before we deep dive into the sample code, let us answer a few frequently asked questions by developers on this topic.<\/p>\n\n\n\n

1.1 What changed with the switch construct, how and when?<\/h3>\n\n\n\n

The humble switch construct has come a long way, and is now available in two flavors – Switch Expressions and Switch Statements. The first change was initiated via Switch Expressions<\/em><\/a>,<\/em> (Java 14), and the addition of Pattern Matching for Switch<\/em><\/a> (Java 21) has revolutionized the ways in which it can be used. In Java 23, you might be able to use primitive types in patterns<\/a> too. <\/p>\n\n\n\n

Unlike a switch statement, Switch expressions can return<\/em> a value, without needing a break<\/code> statement at the end of each case label. Pattern matching for switch significantly reduces the count of lines of code you need for an equivalent if-else construct. It enables you to switch on a lot of data types rather than just a handful of primitives, enums and String (as was the case with the older switch constructs). With pattern matching for switch, you can handle null values as a case label, match different data types or record patterns<\/a> and initialize pattern variables. You can also refine the conditions in case labels by using when<\/code>, and much more. Targeted for Java 23, switch patterns would be able to include primitive data types in patterns.<\/p>\n\n\n\n

However, changes to the switch construct over multiple Java version releases have left some developers confused – regarding the different changes that were added to it or dropped, current state of affairs and the ways it can be used now. <\/p>\n\n\n\n

1.2 Why are developers confused about the changes made to switch?<\/h3>\n\n\n\n

With Java’s six-month release cadence, changes to its existing language features, like the switch construct, or addition of new features like the Pattern Matching, are introduced as  preview feature<\/em><\/a> – features that are complete, but impermanent. <\/p>\n\n\n\n

Such features might take up to two or more Java versions to become permanent in the language. For example, Switch Expressions was introduced in Java 12, but was permanently added in Java in its version 14. Sometimes it is confusing to remember when a feature was introduced or if it is still in preview. Though developers are encouraged to try out or experiment with the preview features, using them in production code is not recommended.<\/p>\n\n\n\n

Also, preview features might<\/em> change over two or more Java versions, until they are permanently added to the Java language. For example, when the Switch Expressions were introduced as a preview language feature in Java 12, its case label used the keyword break<\/em> to return a value, which was later changed to the keyword yield<\/em>. Though these changes are few, they might add up to the confusion – what was changed, and when? Talking about \u2018when\u2019, guarded patterns in Java 17 and 18 used &<\/em> to define a guarded pattern, which has been changed to the usage of when<\/em> since Java version 19. A preview feature could be dropped altogether if sufficient feedback suggests that. Raw String Literals<\/a> is one such example. <\/p>\n\n\n\n

1.3 Why were \u2018switch\u2019 constructs not used enough in the past?<\/h3>\n\n\n\n

Sequence, condition and iteration\u2014are the three basic programming structures to create instructions or algorithms in our code bases.<\/p>\n\n\n\n

When it comes to defining conditions; nothing beats the if<\/code>\/ if-else<\/code> constructs. You have used them to define the simplest or the most complex conditions, using any type of variables or constants. So, we developers usually preferred if\/ if-else constructs over other options like the (old) switch construct and ternary operators for defining conditions because the later two had very limited capabilities.<\/p>\n\n\n\n

1.4 Why bother using \u2018switch\u2019 now?<\/h3>\n\n\n\n

With all the changes that I mentioned in the previous sections, switch is the new cool kid on the block. It can also be used in use cases where only if-else could be used earlier. Also, developers realized that if\/ if-else constructs have disadvantages too\u2014the long if\/else<\/code> constructs are not easy to read. They can\u2019t force developers to define a set of conditions at the language level (you might need an else<\/code> condition even when it is not needed). Also, optimizing code that uses if\/ if-else is difficult and has O(n) time complexity, as opposed to O(1) time complexity for switch. <\/p>\n\n\n\n

Let’s work with coding examples to understand benefits of using the new evolved switch in everyday coding.<\/p>\n\n\n

2. Returning values with Switch Expressions<\/h2>\n

As compared to the \u2018old\u2019 switch constructs, switch expressions can return a value, starting with Java 14. Why is this a big deal? Let\u2019s find out using a few commonly occurring use cases.<\/p>\n

2.1. Replace switch statement with concise switch expressions<\/h3>\n

Imagine a common use case of calculating a discount for an order via a formula (lambda) that depends on a customer\u2019s loyalty card type and their loyalty points. Before switch expressions, you might code this functionality using a switch statement (that can\u2019t return a value) as shown in the code below.<\/p>\n

It was common to switch over the card type owned by a customer, create a local variable, say, result<\/code>, at the beginning of the method, conditionally assign the lambda to calculate the discount in each switch case, and return its value at the end of the method (assume that the variable a<\/code> represents the order total and variable b<\/code> represents the points accumulated in the customer\u2019s loyalty card):<\/p>\n

\nenum CardType {SILVER, GOLD, PLATINUM, DIAMOND}\n\nprivate static BiFunction<Double, Integer, Double> getOrderDiscountFormula(CardType cardType) {\n    BiFunction<Double, Integer, Double> result;\n    switch (cardType) {\n        case SILVER:\n            result = (a, b) -> (a * 0) + b;\n            break;\n        case GOLD:\n            result = (a, b) -> (a * .05) + b;\n            break;\n        case PLATINUM:\n            result = (a, b) -> (a * 0.1) + b * 2;\n            break;\n        case DIAMOND:\n            result = (a, b) -> (a * 0.15) + b * 3;\n            break;\n        default:\n            throw new IllegalArgumentException("Unexpected value: " + cardType);\n    }\n    return result;\n}<\/pre>\n
Whenever you see, hear or experience the word repetition (in the coding or development ecosystem), beware! That is the perfect place for bugs to hide.<\/p>\n
The preceding code has multiple issues:<\/p>\n