java 17 switch assignment

InfoQ Software Architects' Newsletter

A monthly overview of things you need to know as an architect or aspiring architect.

View an example

We protect your privacy.

InfoQ Dev Summit Boston (June 24-25): Learn from senior software practitioners navigating today's critical dev priorities. Register Now

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

• English edition
• Chinese edition
• Japanese edition
• French edition

Back to login

Login with:

Don't have an infoq account, helpful links.

• About InfoQ
• InfoQ Editors

Write for InfoQ

• About C4Media

Choose your language

Learn practical strategies to clarify critical development priorities. Register now.

There are only a few days to save up to 60% off with the special Summer Sale.

Level up your software skills by uncovering the emerging trends you should focus on. Register now.

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage Articles A Comprehensive Guide to Java's New Feature: Pattern Matching for Switch

A Comprehensive Guide to Java's New Feature: Pattern Matching for Switch

This item in japanese

Jun 27, 2023 19 min read

Deepak Vohra

reviewed by

A N M Bazlur Rahman

Key Takeaways

• Pattern matching for the switch control-flow statement is a new feature introduced in Java 17 and refined in subsequent versions.
• A pattern can be used in case labels as case p . The selector expression is evaluated, and the resulting value is tested against the case labels that may include patterns. The execution path of the first matching case label applies to the switch statement/expression.
• Pattern matching adds support for a selector expression of any reference type in addition to the existing legacy types.
• Guarded patterns can be used with the new when clause in a case label pattern.
• Pattern matching can be used with the traditional switch statements and with the traditional fall-through semantics of a switch statement.

A switch statement is a control-flow statement that was originally designed to be a short-form alternative to the if-else if-else control-flow statement for certain use cases that involved multiple possible execution paths based on what a given expression evaluates to.

A switch statement consists of a selector expression and a switch block consisting of case labels ; the selector expression is evaluated, and the execution path is switched based on which case label matches the result of the evaluation.

Originally switch could only be used as a statement with the traditional case ...: label syntax with fall-through semantics. Java 14 added support for the new case ...-> label syntax with no fall-through semantics.

Related Sponsored Content

The definitive guide to designing a responsive data architecture, related sponsor.

RavenDB Document Database. Chillax during development, forget about maintenance. Check out why it matters and give us a try .

Java 14 also added support for switch expressions . A switch expression evaluates to a single value. A yield statement was introduced to yield a value explicitly.

Support for switch expressions, which is discussed in detail in another article , means that switch can be used in instances that expect an expression such as an assignment statement.

However, even with the enhancements in Java 14, the switch still has some limitations:

• The selector expression of switch supports only specific types, namely integral primitive data types byte , short , char , and int ; the corresponding boxed forms Byte , Short , Character , and Integer ; the String class; and the enumerated types.
• The result of the switch selector expression can be tested only for exact equality against constants. Matching a case label with a constant test only against one value.
• The null value is not handled like any other value.
• Error handling is not uniform.
• The use of enums is not well-scoped.

A convenient solution has been proposed and implemented to counter these limitations: pattern matching for switch statements and expressions. This solution addresses all the issues mentioned above.

Pattern matching for the switch was introduced in JDK 17, refined in JDK 18, 19, and 20, and is to be finalized in JDK 21.

Pattern matching overcomes the limitations of the traditional switch in several ways:

• The type of the selector expression can be any reference type in addition to an integral primitive type (excluding long ).
• Case labels can include patterns in addition to constants. A pattern case label can apply to many values, unlike a constant case label that applies to only one value. A new case label, case p , is introduced in which p is a pattern.
• Case labels can include null .
• An optional when clause can follow a case label for conditional or guarded pattern matching. A case label with a when is called a guarded case label.
• Enum constant case labels can be qualified. The selector expression doesn’t have to be an enum type when using enum constants when using enum constants.
• The MatchException is introduced for a more uniform error handling in pattern matching.
• The traditional switch statements and the traditional fall-through semantics also support pattern matching.

A benefit of pattern matching is to facilitate data oriented programming , such as improving the performance of complex data-oriented queries.

What is pattern matching?

Pattern matching is a powerful feature that extends the functionality of control-flow structures in programming. This feature allows a selector expression to be tested against several patterns in addition to the test against traditionally supported constants. The semantics of the switch stays unchanged; a switch selector expression value is tested against case labels that may include patterns, and if the selector expression value matches a case label pattern, that case label applies to the execution path of the switch control-flow. The only enhancement is that the selector expression can be any reference type in addition to primitive integral types (excluding long). The case labels can include patterns in addition to constants. Additionally, supporting null and qualified enum constants in case labels is an added feature.

The grammar of switch labels in a switch block is as follows:

Pattern matching can be used with the traditional case …: label syntax with fall-through semantics, and with the case … -> label syntax with no fall-through semantics. Nonetheless, it’s essential to note that a switch block cannot mix the two types of case labels.

With these modifications in place, pattern matching has paved the way for more sophisticated control-flow structures, transforming the richer way to approach logic in code.

Setting the environment

The only prerequisite to running the code samples in this article is to install Java 20 or Java 21 (if available). Java 21 makes only one enhancement over Java 20, which is support for qualified enum constants in case labels. The Java version can be found with the following command:

Because switch pattern matching is a preview feature in Java 20, javac and java commands must be run with the following syntax:

However, one can directly run this using the source code launcher . In that case, the command line would be:

The jshell option is also available but requires enabling the preview feature as well:

A simple example of pattern matching

We start with a simple example of pattern matching in which the selector expression type of a switch expression is reference type; Collection; and the case labels include patterns of the form case p .  

Compile and run the Java application, with the output:

Pattern matching supports all reference types

In the example given earlier, the Collection class type is used as the selector expression type. However, any reference type can serve as the selector expression type. Therefore, the case label patterns can be of any reference type compatible with the selector expression value. For example, the following modified SampleClass uses an Object type selector expression and includes case label patterns for a record pattern and an array reference type pattern, in addition to the case label patterns for previously used Stack , LinkedList , and Vector reference types.

This time the output is as follows:

The null case label

Traditionally, a switch throws a NullPointerException at runtime if the selector expression evaluates to null . A null selector expression is not a compile-time issue. The following simple application with a match-all case label default demonstrates how a null selector expression throws a NullPointerException at runtime.

It is possible to test a null value explicitly outside the switch block and invoke a switch only if non-null, but that involves adding if-else code. Java has added support for the case null in the new pattern matching feature. The switch statement in the following application uses the case null to test the selector expression against null.

At runtime, the application outputs:

The case null can be combined with the default case as follows:

However, the case null cannot be combined with any other case label. For example, the following class combines the case null with a case label with a pattern Stack s :

The class generates a compile-time error:

Guarded patterns with the when clause  

Sometimes, developers may use a conditional case label pattern that is matched based on the outcome of a boolean expression. This is where the when clause comes in handy. This clause evaluates a boolean expression, forming what is known as a 'guarded pattern.' For example, the when clause in the first case label in the following code snippet determines if a Stack is empty.

The corresponding code, located to the right of the ' -> ', only executes if the Stack is indeed empty.

The ordering of the case labels with patterns is significant

When using case labels with patterns, developers must ensure an order that doesn't create any issues related to type or subtype hierarchy. That is because, unlike constant case labels, patterns in case labels allow a selector expression to be compatible with multiple case labels containing patterns. The switch pattern matching feature matches the first case label, where the pattern matches the value of the selector expression.  

If the type of a case label pattern is a subtype of the type of another case label pattern that appears before it, a compile-time error will occur because the latter case label will be identified as unreachable code.  

To demonstrate this scenario, developers can compile and run the following sample class in which a case label pattern of type Object dominates a subsequent code label pattern of type Stack .

When compiling the class, an error message is produced:

The compile-time error can be fixed simply by reversing the order of the two case labels as follows:

Similarly, if a case label includes a pattern that is of the same reference type as a preceding case label with an unconditional/unguarded pattern (guarded patterns discussed in an earlier section), it will result in a  compile-type error for the same reason, as in the class:

Upon compilation, the following error message is generated:

To avoid such errors, developers should maintain a straightforward and readable ordering of case labels. The constant labels should be listed first, followed by the case null label, the guarded pattern labels, and the non-guarded type pattern labels. The default case label can be combined with the case null label, or placed separately as the last case label. The following class demonstrates the correct ordering:

Pattern matching can be used with the traditional switch statement and with fall-through semantics

The pattern-matching feature is independent of whether it is a switch statement or a switch expression. The pattern matching is also independent of whether the fall-through semantics with case …: labels, or the no-fall-through semantics with the case …-> labels is used. In the following example, pattern matching is used with a switch statement and not a switch expression. The case labels use the fall-through semantics with the case …: labels. A when clause in the first case label uses a guarded pattern.  

Scope of pattern variables

A pattern variable is a variable that appears in a case label pattern. The scope of a pattern variable is limited to the block, expression, or throw statement that appears to the right of the -> arrow. To demonstrate, consider the following code snippet in which a pattern variable from a preceding case label is used in the default case label.

A compile-time error results:

The scope of a pattern variable that appears in the pattern of a guarded case label includes the when clause, as demonstrated in the example:

Given the limited scope of a pattern variable, the same pattern variable name can be used across multiple case labels. This is illustrated in the preceding example, where the pattern variable s is used in two different case labels.

When dealing with a case label with fall-through semantics, the scope of a pattern variable extends to the group of statements located to the right of the ' : '. That is why it was possible to use the same pattern variable name for the two case labels in the previous section by using pattern matching with the traditional switch statement. However, fall through case label that declares a pattern variable is a compile-time error. This can be demonstrated in the following variation of the earlier class:

Without a break; statement in the first statement group, the switch could fall-through the second statement group without initializing the pattern variable v in the second statement group. The preceding class would generate a compile-time error:

Simply adding a break; statement in the first statement group as follows fixes the error:

Only one pattern per case label

Combining multiple patterns within a single case label, whether it is a case label of the type case …: , or the type case …->   is not allowed, and it is a compile-time error. It may not be obvious, but combining patterns in a single case label incurs fall-through a pattern, as demonstrated by the following class.

A compile-time error is generated:

Only one match-all case label in a switch block

It is a compile-time error to have more than one match-all case labels in a switch block, whether it is a switch statement or a switch expression. The match-all case labels are :

• A case label with a pattern that unconditionally matches the selector expression
• The default case label

To demonstrate, consider the following class:

Compile the class, only to get an error message:

The exhaustiveness of type coverage

Exhaustiveness implies that a switch block must handle all possible values of the selector expression. The exhaustiveness requirement is implemented only if one or more of the following apply:

• a) Pattern switch expressions/statements are used,
• b) The case null is used,
• c) The selector expression is not one of the legacy types ( char , byte , short , int , Character , Byte , Short , Integer , String , or an enum type).

To implement exhaustiveness, it may suffice to add case labels for each of the subtypes of the selector expression type if the subtypes are few.  However, this approach could be tedious if subtypes are numerous; for example, adding a case label for each reference type for a selector expression of type Object , or even each of the subtypes for a selector expression of type Collection , is just not feasible.

To demonstrate the exhaustiveness requirement, consider the following class:

The class generates a compile-time error message:

The issue can be fixed simply by adding a default case as follows:

A match-all case label with a pattern that unconditionally matches the selector expression, such as the one in the following class, would be exhaustive, but it wouldn’t handle or process any subtypes distinctly.

The default case label could be needed for exhaustiveness but could sometimes be avoided if the possible values of a selector expression are very few. As an example, if the selector expression is of type java.util.Vector , only one case label pattern for the single subclass java.util.Stack is required to avoid the default case. Similarly, if the selector expression is a sealed class type, only the classes declared in the permits clause of the sealed class type need to be handled by the switch block.

Generics record patterns in switch case label

Java 20 adds support for an inference of type arguments for generic record patterns in switch statements/expressions. As an example, consider the generic record:

In the following switch block, the inferred record pattern is

Error handling with MatchException

Java 19 introduces a new subclass of the java.lang.Runtime class for a more uniform exception handling during pattern matching. The new class called java.lang.MatchException is a preview API. The MatchException is not designed specifically for pattern matching in a switch but rather for any pattern-matching language construct. MatchException may be thrown at runtime when an exhaustive pattern matching does not match any of the provided patterns. To demonstrate this, consider the following application that includes a record pattern in a case label for a record that declares an accessor method with division by 0.

The sample application compiles without an error but at runtime throws a MatchException :

This article introduces the new pattern-matching support for the switch control-flow construct. The main improvements are that switch's selector expression can be any reference type, and the switch's case labels can include patterns, including conditional pattern matching. And, if you rather not update your complete codebase, pattern matching is supported with traditional switch statements and with traditional fall-through semantics.  

About the Author

Rate this article, this content is in the java topic, related topics:.

• Development

Related Editorial

Popular across infoq, retrieval-augmented generation (rag) patterns and best practices, introducing the rig model - the puzzle of designing guaranteed data-consistent microservice systems, optimizing spring boot config management with configmaps: environment variables or volume mounts, cloudflare ai gateway now generally available, edo liberty on vector databases for successful adoption of generative ai and llm based applications, liquid: a large-scale relational graph database, related content, the infoq newsletter.

A round-up of last week’s content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers. View an example

Pattern matching for switch in Java (JDK 17)

• Old problems, new ways of solving it?
• The data model
• The visitor pattern
• The naive non-visitor pattern implementation with if statements
• Say hello to the switch expressions
• Also greet the pattern matching for switch
• The guard pattern
• About instanceof /casting and switch on types
• Looking at the Java pattern future

Old problems, new ways of solving it? #

If all you have is a hammer, everything looks like a nail.

This sentence summarizes pretty much how I felt about the idiomatic polymorphism approach in Java to most problems until recently. Polymorphism is just a tool and as for any tool, it excels at some tasks and performs poorly at others.

So what are the tasks where polymorphism does a good job at?

I would say it is a good tool when you have a few functions operating on a potentially large or unknown number of data types. Or when the number of types will vary over time. This model is more behavior-centric where every data type brings its behavior to a fixed and small set of functions.

However, there is another use case where a fixed and small set of data types exists, and an unknown number of functions rely on those types as a group. A typical example is a tree, graph, or other recursive data structure where it is difficult for a function to have a meaning as part of the types themselves.

This second use case is usually covered in Java using the Visitor pattern . This is, unfortunately, not the most transparent or straightforward design pattern.

But with the recent improvements and preview features in the JDK 17 , can we do better?

Example: Simplifying a boolean expression #

Before going into a code example, let’s first agree on the problem to tackle. We will implement a boolean expression NOT simplifier.

Why choosing a boolean expression for this example? A boolean expression is something very simple to model and understand. However, there are very few core operations on a boolean expression. Evaluating is one of those, but simplifying an expression is not part of it as there are too many moving parts or ways to do so. Hence the regular approach would use a visitor pattern.

The data model #

We will have an Expression interface with a few default methods and static factories and four records types implementing it:

Records were introduced in JDK 16 via JEP 395: Records after two previews in JDK 14 and JDK 15 . I encourage you to read the article Why Java’s Records Are Better* Than Lombok’s @Data and Kotlin’s Data Classes from Nicolai Parlog . It is a very detailed dive into what records are and what they’re not.

The goal is to implement a method with the following signature:

The visitor pattern #

I have some respect for you and I will therefore spare you the full implementation of the visitor pattern. If you’re still interested in the implementation, it is available on Github .

The naive non-visitor pattern implementation with if statements #

In Java 15 and before, without using preview features, we would have had to write something like this:

This approach has two issues:

It is lengthy as we do redundant instanceof /casts

It is not proven complete at compilation time, hence the need to throw UnsupportedOperationException if no condition is met. In case a sub-type to Expression is added, the compiler will not tell us, and we might only discover it only at runtime.

Since Java 15, we can improve the first point by leveraging on JEP 394: Pattern Matching for instanceof . It avoids the cumbersome casts and allows to rewrite code:

into this one:

Applying it to our example, it would look like this:

That’s how far we can get with the if / else approach. We cannot unfortunately have completeness checked by the compiler at this point.

The switch-based approach #

Say hello to the switch expressions #.

Using a switch-based approach, we would improve readability and could potentially tackle the completeness issue. But for this, we need JEP 361: Switch Expressions which was introduced in JDK 14 after two previews.

This allows to rewrite the following code in a much nicer way:

As you can see, the throw clause disappeared because a completeness check is performed. A compilation error is thrown if not all cases are covered. Assuming we remove the case WEDNESDAY , the following compilation error is raised:

This is a great addition that makes switch more robust than if / else as you’ll be warned at compilation time if not all branches are covered. The JEP also states the following to cover potential runtimes issues:

in the case of an enum switch expression that covers all known constants, a default clause is inserted by the compiler to indicate that the enum definition has changed between compile-time and runtime.

Now, this is not enough for us as we would like to perform our switch on the object type.

Also greet the pattern matching for switch #

To achieve this, we need to rely on JEP 406: Pattern Matching for switch (Preview) from JDK 17 .

To give a rough idea of what this is about, you can think of it as if JEP 394: Pattern Matching for instanceof and JEP 361: Switch Expressions had a baby.

So, let’s take a look at our code with this amazing feature:

Wait, why do we have to include this default clause? Remember when we said that switch expressions must be complete? Not doing so would result in a compiler error: the switch expression does not cover all possible input values .

That’s not very nice to have. Especially as we know, that they are only four implementations of the Expression interface. However, the compiler does not know it.

But there is a way to let the compiler know and to enforce it. This is thanks to the JEP 409: Sealed Classes from JDK 17 . So much goodness in this JDK 17.

We can now explicitly say that Expression is one of Variable , And , Or or Not and nothing else.

Let’s update the interface declaration to represent it:

If we now try to declare a Xor expression which can also be expressed as: (A OR B) AND (NOT(A) OR NOT(B)) we will get the following compilation error:

Going back to the switch we can now express it without the need for the default clause:

This is it, we reached our goal thanks to JEP 406: Pattern Matching for switch (Preview) .

The guard pattern #

We did not need this feature in our little example, but this JEP also defines the notion of guard patterns. With guard patterns, an additional boolean expression can be added next to the type pattern.

One can replace the following code:

About instanceof /casting and switch on types #

It used to be strongly discouraged to perform instanceof / cast operations in if statements and conceptually out of reach for switch statements.

Why do we start to do so now?

I haven’t played enough with instanceof and casting in my career to have an answer to this part. I was most of the time creative enough to avoid being in such a situation and I feel I would need to unlearn first to be able to provide a decent answer here.

However, when it comes to the switch , it feels like a very handy replacement for the visitor design pattern.

They were two major complaints against the switch :

implementation far from the type and scattered across the codebase

The visitor pattern has the same issue, so wherever the visitor pattern was good for, the pattern matching for switch is also good enough.

completeness: When a new type/constant is added, the if / else / switch will not complain at compilation time and issues will arise at runtime.

Here, the switch expression solves the issue by checking for completeness. If a new type/case is added, a compilation error will arise. Unless a manual default clause has been written. So when writing switch-expressions, be aware of the hidden cost of the default clause and try to favor the usage of sealed types.

Looking at the Java pattern future #

This article covered the yet-to-be-released JEP 406: Pattern Matching for switch (Preview) and how it enables the Java language to express more, more clearly.

The code can be found on Github .

But can we look even further? In JDK 18 and beyond for example? As of June 20th, 2021, the list of JEP that will land in JDK 18 is not yet known. But we do know about one candidate which is JEP 405: Record Patterns & Array Patterns (Preview) .

This will bring deconstruction patterns for both Arrays and Records.

We could then imagine writing things like:

Or even, all in one switch:

The JEP even says the following:

Today, to express ad-hoc polymorphic calculations like this we would use the cumbersome visitor pattern. In the future, using pattern matching will lead to code that is transparent and straightforward

Keep in mind, this last part regarding JEP 405: Record Patterns & Array Patterns (Preview) is based on my current understanding of the JEP and that the JEP will evolve before making it into the JDK.

To conclude I’d like to say this:

What seemed to be unrelated JEPs in the beginning, switch expressions, records, pattern matching (instance of, switch), deconstruction patterns, is slowly but surely converging toward a highly consistent and well-thought design which I can’t stop being amazed at.

Adam Gamboa G – Developer

Full Stack notes and tips for developers… Java, React, Kubernetes, Scala, and more…

Switch expression on Java 17

Java 17 has come up with some cool features for the language, one of which is switch expressions. Maybe someone wonders, – But, does the switch already exists in Java? and the answer is yes , as a statement that only evaluates a data but does not return a value. That is the difference, being an expression it can return values, also include patterns to the case.

It is important to note that switch expressions have been in the language since previous versions of Java, starting in Java 12 in preview mode and receiving constant improvements with the following versions of Java. It is up to Java 17 that it is available in a stable long support (LTS) release.

This is the first step towards a more declarative and “null-safe” programming style, allowing a better way to express and model data, recognizing the semantics of the data model through patterns. Definitively improving the readability of our code, avoiding nested if/elseif/else for many circumstances, and providing features that we see in other programming languages.

Let’s take the following code as reference, with some if/else if and instanceof .

The previous code can be converted with a switch expression.

Switch Expression vs Switch Statement

Now, how are the switch expression and statement going to co-exist? The first difference is in the operator used after the case , the expression uses an arrow -> while the statement continues using the operator : (colon).

It can be noticed that in the switch statement is still necessary to use the break statement to terminate the switch flow, in other words, if break is not indicated, it will continue executing the code blocks of the following labels. On the other hand, in the switch expression , only the code block of the matching pattern or value is executed.

It should be noted that both the sentence and the expression continue to work with exact or constant values, not only with patterns that it matches. For example, the following code is still valid.

Support of null

Traditionally, the switch throws a NullPointerException when the value is null . This behavior is still present for existing switch statements, which do not make use of patterns. However, to make the new features of the switch more user-friendly (both the statement and the expression) allow null as part of the pattern.

Guarded Pattern

This is a feature that I have seen in other languages and I think it was very successful that it is being added in Java as well. The “guarded pattern” is a condition that is part of an expression that must be matched and is preceded by the && operator.

There are many other features of the switch that are not listed in this article, however, it is about showing the main ones, which I believe can provide a great improvement in usability to our code.

Definitely, Java as a language continues to evolve and provide features that will further simplify our code and keep it on par with many other new languages that are trending at the moment.

• https://openjdk.java.net/jeps/406
• https://www.infoworld.com/article/3606833/jdk-17-the-new-features-in-java-17.html

Hi and thank you so much for the above article. I am typing your code into IDE, and I get a compiler error saying “Patterns in switch are not support at language level 19” public static String formattedWithSwith(Object o){ return switch (o){ case Integer i-> String.format(“int i”,i); default -> o.toString(); }; } I get the red squiggly right under the “i”

I think it should be an issue of the IDE, for example it has been reported for IntelliJ on other versions of Java.

https://youtrack.jetbrains.com/issue/IDEA-295898

But the code compiles correctly. Can you verify that compiling your code the issue is not happening? If so, then it’s just the IDE which doesn’t have support for that new feature in Java. Hopefully new versions of the IDE will fix it.

P.S. I am using OpenJDK

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Social Links

Most viewed posts.

• Switch expression on Java 17 (33,805)
• Maven Central Repository is moving to HTTPS and disablig HTTP access (29,447)
• Using JPA CriteriaQuery to build Paginated Queries (25,616)
• How to set environment variable in MacOS (24,772)
• Spring Data JPA and the Specification Pattern (18,968)
• Architecture
• Cheat Sheet

Recent Posts

• Integrating dropwizard metrics with prometheus metrics
• Moving data from Database to AWS S3 with Apache Spark
• Docker Image Best Practices
• Jakarta Data – An unified API for Persistence
• Java 21 Features – Overview

Pattern Matching for Switch

Available in preview from java 17.

Helen Scott

editing    java    refactoring   

Ensure your SDK and Language Level are at least Java 17 (Preview) in your Project Structure with ⌘; (macOS) / Ctrl+Alt+Shift+S (Windows/Linux).

IntelliJ IDEA highlights code that can be replaced with a switch expression using pattern variables. Press ⌥⏎ (macOS) / Alt+Enter (Windows/Linux) and choose "Replace if with switch ".

• (blog) Java 17 and IntelliJ IDEA

Related Resources

Modern Java Switch Expressions

In this blog, I will cover some improvements of switch. The old syntax dates back to the early day of Java, and its handling is a bit cumbersome.

Let's look at the newer, slightly modified syntax for switch, called Switch Expressions. With it, case distinctions can be formulated much more elegantly than before.

Introductory example

To demonstrate switch expressions, I resort to mapping days of the week to their textual length as an example.

To better understand the need for this syntax improvement, let’s first examine how this task would have been formulated with the old syntax. Afterwards, we’ll look at the advantages provided by the new syntax of switch.

Analysis: What were some weaknesses of the switch so far?

Let’s start with the implementation of mapping weekdays of type DayOfWeek to their textual length using the older syntax:

Modern Switch Expressions

Let's have a critical look at the source code. First of all, the shown construct does not appear elegant and is also quite long. The multiple specifications of values need accustoming, too. Even worse, a break is needed so that the processing runs without surprise and there is no fall-through. Moreover, we need to set the (artificial) auxiliary variable numOfLetters correctly in each branch. In particular, despite the actually complete coverage of the enum values, the default is necessary. Otherwise, the compiler complains that the variable numOfLetters may not be initialized – unless you have already assigned a value to it initially. So how is it better?

Syntax of the new Switch Expressions

With the new "Switch Expressions", expressing case distinctions is made much easier and provides an intuitive notation:

From this example, we notice some syntactic innovations: In addition to the obvious arrow instead of the colon, multiple values can now be specified after the case. Conveniently, there is no more need for break: The statements after the arrow are only executed specifically for the case and no fall-through exists with this syntax. Besides, the switch can now return a value, which avoids the need to define auxiliary variables. Instead of just stating a value after the arrow, it is also possible to specify expressions such as assignments or method calls without any problems. And even better, of course, still without the need for a break. Furthermore, this is no longer allowed in the new syntax after the arrow. 

Special feature: completeness check 

In the old version of switch it was possible to omit the default or to specify a case for individual values, for example WEDNESDAY. The compiler wouldn't have recognized this in switch itself. This would only have been pointed out later when accessing the variable used in the example that it is not initialized in every case. 

The handling has conveniently improved with the new switch expressions: Let’s assume we did not specify WEDNESDAY in the above example. Then this is directly criticized by the compiler: "A switch expression should cover all possible values." Additionally, IDEs offer the choice of adding either the appropriate case or a default, but not both: full coverage of the enum values is automatically detected. This innovation is necessary because the switch must now return a value in each case.

While it is still quite clear for enums with a limited set of possible values, the following question arises: How does it work for other types, such as ints? In such cases, the compiler can only state that possibly not all values are covered, and complains: "A switch expression should cover all possible values." Then the IDEs suggest to add a default – here indicated by the line commented out:

Other reasons for the innovation

Let me go into more detail about the completeness check of the value coverage in the cases because there are sometimes difficulties when using switch. 

Pitfall 1: Incomplete value specifications

With the Date and Time API, of course, the complicated construct could be simplified significantly: month.getDisplayName(TextStyle.FULL, Locale.UK).

‍ In the following, we want to map a value from the enumeration java.time.Month to the corresponding month name. Conventionally, this can be solved somewhat as follows:

Again, the shown construct is not really elegant. Depending on whether a case is de fined for the value Month.JULY or not, one gets the value "July" or "N/A". Also, a break is needed to ensure that the processing is performed without surprise. 

Pitfall 2: Fall-through and default between the breaks

‍ Let’s consider something rather clumsy, namely the default in the middle of the cases and without a break:

The input Month.FEBRUARY results in the value "February" as expected, but surprisingly this also happens for the input Month.JULY. Why is this? First, because of the cases unlisted value JULY, the default branch is executed. Because of the missing break, a fall-through is also (unexpectedly) triggered. This causes the code for case FEBRUARY to be executed, which can be quite confusing. 

Remedy with the new switch expressions

‍ With the help of the new syntax, the whole thing is much easier to write as follows: 

It is especially worth mentioning that one can directly return the value calculated by the switch construct. Furthermore, the fall-through does not occur. Thus the input Month.FEBRUARY returns "February" as expected, and moreover the default in the middle of the cases is not quite as dramatic, though certainly not pretty either. Unlike the old syntax, the input Month.JULY just no longer results in an unexpected output "February", but as specified by default in "N/A". Furthermore, if there were a case JULY, it would always be executed, regardless of the position of the default, thus analogous to the behavior of the previous switch statement.

Conclusion 

The Java releases up to and including 13 are rather manageable in terms of their innovations. This is true even for Java 11 as an LTS version. Fortunately, Java 14 brings a good slew of useful enhancements: On the one hand, there are the convenient syntax changes in switch. Another is the multi-line strings, called Text Blocks. These are covered in one of the next blogs. 

Let me conclude: The new syntax of switch seems to be just a small change, but it has an enormous effect on readability and ease of use. This blog introduced the benefits and simplifications of the new syntax of switch so that you can profit from it in your own projects.

What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

Holen Sie sich Ihren kostenlosen Leitfaden zum erfolgreichen Employer Branding!

Continue reading, the best programming language for beginners to learn in 2024, how many jobs are available in technology, is software engineering hard, subscribe to devdigest.

Get a weekly, curated and easy to digest email with everything that matters in the developer world.

From developers. For developers.

Pattern Matching for instanceof in Java 14

Last updated: January 16, 2024

• >= Java 11

Now that the new version of REST With Spring - “REST With Spring Boot” is finally out, the current price will be available until the 22nd of June , after which it will permanently increase by 50$

>> GET ACCESS NOW

Azure Spring Apps is a fully managed service from Microsoft (built in collaboration with VMware), focused on building and deploying Spring Boot applications on Azure Cloud without worrying about Kubernetes.

The Enterprise plan comes with some interesting features, such as commercial Spring runtime support, a 99.95% SLA and some deep discounts (up to 47%) when you are ready for production.

>> Learn more and deploy your first Spring Boot app to Azure.

And, you can participate in a very quick (1 minute) paid user research from the Java on Azure product team.

Slow MySQL query performance is all too common. Of course it is. A good way to go is, naturally, a dedicated profiler that actually understands the ins and outs of MySQL.

The Jet Profiler was built for MySQL only , so it can do things like real-time query performance, focus on most used tables or most frequent queries, quickly identify performance issues and basically help you optimize your queries.

Critically, it has very minimal impact on your server's performance, with most of the profiling work done separately - so it needs no server changes, agents or separate services.

Basically, you install the desktop application, connect to your MySQL server , hit the record button, and you'll have results within minutes:

>> Try out the Profiler

A quick guide to materially improve your tests with Junit 5:

Do JSON right with Jackson

Download the E-book

Get the most out of the Apache HTTP Client

Get Started with Apache Maven:

Get started with Spring and Spring Boot, through the reference Learn Spring course:

>> LEARN SPRING

Building a REST API with Spring?

The AI Assistant to boost Boost your productivity writing unit tests - Machinet AI .

AI is all the rage these days, but for very good reason. The highly practical coding companion, you'll get the power of AI-assisted coding and automated unit test generation . Machinet's Unit Test AI Agent utilizes your own project context to create meaningful unit tests that intelligently aligns with the behavior of the code. And, the AI Chat crafts code and fixes errors with ease, like a helpful sidekick.

Simplify Your Coding Journey with Machinet AI :

>> Install Machinet AI in your IntelliJ

Get non-trivial analysis (and trivial, too!) suggested right inside your IDE or Git platform so you can code smart, create more value, and stay confident when you push.

Get CodiumAI for free and become part of a community of over 280,000 developers who are already experiencing improved and quicker coding.

Write code that works the way you meant it to:

>> CodiumAI. Meaningful Code Tests for Busy Devs

Looking for the ideal Linux distro for running modern Spring apps in the cloud?

Meet Alpaquita Linux : lightweight, secure, and powerful enough to handle heavy workloads.

This distro is specifically designed for running Java apps . It builds upon Alpine and features significant enhancements to excel in high-density container environments while meeting enterprise-grade security standards.

Specifically, the container image size is ~30% smaller than standard options, and it consumes up to 30% less RAM:

>> Try Alpaquita Containers now.

Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.

I built the security material as two full courses - Core and OAuth , to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project .

You can explore the course here:

>> Learn Spring Security

DbSchema is a super-flexible database designer, which can take you from designing the DB with your team all the way to safely deploying the schema .

The way it does all of that is by using a design model , a database-independent image of the schema, which can be shared in a team using GIT and compared or deployed on to any database.

And, of course, it can be heavily visual, allowing you to interact with the database using diagrams, visually compose queries, explore the data, generate random data, import data or build HTML5 database reports.

>> Take a look at DBSchema

Creating PDFs is actually surprisingly hard. When we first tried, none of the existing PDF libraries met our needs. So we made DocRaptor for ourselves and later launched it as one of the first HTML-to-PDF APIs.

We think DocRaptor is the fastest and most scalable way to make PDFs , especially high-quality or complex PDFs. And as developers ourselves, we love good documentation, no-account trial keys, and an easy setup process.

>> Try DocRaptor's HTML-to-PDF Java Client (No Signup Required)

Get started with Spring Boot and with core Spring, through the Learn Spring course:

>> CHECK OUT THE COURSE

1. Overview

In this quick tutorial, we’ll continue our series on Java 14 by taking a look at Pattern Matching for instanceof which is another new preview feature included with this version of the JDK.

In summary, JEP 305 aims to make the conditional extraction of components from objects much simpler, concise, readable and secure.

2. Traditional instanceOf Operator

At some point, we’ve probably all written or seen code that includes some kind of conditional logic to test if an object has a specific type. Typically, we might do this with the instanceof operator followed by a cast . This allows us to extract our variable before applying further processing specific to that type.

Let’s imagine we want to check the type in a simple hierarchy of animal objects:

In this example, for each conditional block, we’re testing the animal parameter to determine its type, converting it via a cast and declaring a local variable. Then, we can perform operations specific to that particular animal.

Although this approach works, it has several drawbacks:

• It’s tedious to write this type of code where we need to test the type and make a cast for every conditional block
• We repeat the type name three times for every if block
• Readability is poor as the casting and variable extraction dominate the code
• Repeatedly declaring the type name means there’s more likelihood of introducing an error . This could lead to an unexpected runtime error
• The problem magnifies itself each time we add a new animal

In the next section, we’ll take a look at what enhancements Java 14 provides to address these shortcomings.

3. Enhanced instanceOf in Java 14

Java 14, via JEP 305, brings an improved version of the instanceof operator that both tests the parameter and assigns it to a binding variable of the proper type.

This means we can write our previous animal example in a much more concise way :

Let’s understand what is happening here. In the first, if block, we match animal  against the type pattern Cat cat . First, we test the animal variable to see if it’s an instance of Cat . If so, it’ll be cast to our Cat type, and finally, we assign the result to cat .

It is important to note that the variable name cat is not an existing variable, but instead a declaration of a pattern variable.

We should also mention that the variables cat and dog are only in scope and assigned when the respective pattern match expressions return true . Consequently, if we try to use either variable in another location, the code will generate compiler errors.

As we can see, this version of the code is much easier to understand. We have simplified the code to reduce the overall number of explicit casts dramatically, and the readability is greatly improved.

Moreover, this kind of type of test pattern can be particularly useful when writing equality methods.

4. Conclusion

In this short tutorial, we looked at Pattern Matching with instanceof  in Java 14. Using this new built-in language enhancement helps us to write better and more readable code, which is generally a good thing.

As always, the full source code of the article is available over on GitHub .

Slow MySQL query performance is all too common. Of course it is.

The Jet Profiler was built entirely for MySQL , so it's fine-tuned for it and does advanced everything with relaly minimal impact and no server changes.

Explore the secure, reliable, and high-performance Test Execution Cloud built for scale. Right in your IDE:

Basically, write code that works the way you meant it to.

AI is all the rage these days, but for very good reason. The highly practical coding companion, you'll get the power of AI-assisted coding and automated unit test generation . Machinet's Unit Test AI Agent utilizes your own project context to create meaningful unit tests that intelligently aligns with the behavior of the code.

• Stack Overflow Public questions & answers
• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Talent Build your employer brand
• Advertising Reach developers & technologists worldwide
• Labs The future of collective knowledge sharing
• About the company

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

How to return values found in a switch statement Java

How would I return the values that I found in this switch statement to the rest of the class for use (I want to use oneTotal, twoTotal, etc. out side of that switch statement)? Here is the code for the switch statement:

Out side of the switch statement I want the fiveTotal's to be added up once the user's stops using the switch statement (I have it in a while loop), and then want the five totals to be returned to be used in the main method of the class (the switch statement is in its own double, non void class so it can return values).

• switch-statement

• Have you tried declaring the variables before the switch statement? –  Andy Turner Feb 16, 2015 at 18:05
• You should avoid declaring variables in a switch statement. –  JNYRanger Feb 16, 2015 at 18:06

11 Answers 11

On Java 14, you can use

• What happens if I put itemNo 99 here? –  Johan Walles Feb 19 at 9:53

Just try defining a variable called result of double type before switch statement like:

• 1 How would I take that and print it out in the main method, when I try to use result it does not seem to work. –  Fyree Feb 16, 2015 at 18:44
• 1 You can call in main method like double result = mymethod(); System.out.println(result); –  SMA Feb 17, 2015 at 4:51

The method must only contain the necessary code to do its work. The consumers of the method must worry about how to work with the data.

For your case, your method containing this switch must only care about returning the proper value based on the parameter(s), and the clients of the method e.g. public static void main(String[] args) must evaluate what to do with the results from executing this method.

Here's how this may work for your case:

• 1 This is not working, it is not changing the value of grandTotal, it just ignore's the user's input and says that the grandTotal is 0.0. Also I want it to be able to add the different values up to form result (so in case 3 for example it would be three = 9.98 * userQuantity;) by adding up the five different values. –  Fyree Feb 16, 2015 at 19:09
• 1 @Fyree make sure double grandTotal is outside your loop, as shown in my code. –  Luiggi Mendoza Feb 16, 2015 at 19:10
• I don't have a loop, should I? –  Fyree Feb 16, 2015 at 19:14
• 1 @Fyree a loop can be one of these: for , while , do-while . You state in your question that you have a while loop, so declare grandTotal before the loop, this is, before the while statement. –  Luiggi Mendoza Feb 16, 2015 at 19:15
• The while loop contains my switch statement, let me edit the code above. –  Fyree Feb 16, 2015 at 21:20

You can create a variable out side the switch statement and is visible for rest of the class to keep track of the return values:

There, you'll have access to the sum after the switch statement. If you want to track each individual return values, simple use an ArrayList.

Hope this helps :)

Define a variable on top of switch statement so that it is visible for switch scope. then assign your value to that variable in each case. Then as last line return your assigned variable.

And don't forget the default branch. Throw an exception at least.

• You can delete the post, edit it as much as you want and then undelete it. –  Luiggi Mendoza Feb 16, 2015 at 18:06

The following should work:

I'm not sure the implementation you are looking to use this in....however it seems like you are on the right track.

Simply wrap your switch statement into a method

edit for passing in argument for whatever your switch value will be apologies...

There are two ways you can go about this depending on what you want to do. First, If you want to just keep adding the sum, you can define a variable outside the function and keep incrementing it.

Or, If you want to have those values distinct then you can keep an array[5]

This was you will can have explicit knowledge outside your switch-case of what the user entered and do any manipulation with the data.

This can also be written as mentioned below,

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged java switch-statement return double user-input or ask your own question .

• The Overflow Blog
• Introducing Staging Ground: The private space to get feedback on questions...
• How to prevent your new chatbot from giving away company secrets
• Featured on Meta
• The [tax] tag is being burninated
• The return of Staging Ground to Stack Overflow
• The 2024 Developer Survey Is Live
• Policy: Generative AI (e.g., ChatGPT) is banned

Hot Network Questions

• Transformer with same size symbol meaning
• How might a physicist define 'mind' using concepts of physics?
• Plausible Far Future "Infantry" main weapons?
• Calculating Living Area on a Concentric Shellworld
• A phrase that means you are indifferent towards the things you are familiar with?
• Is it legal to deposit a check that says pay to the order of cash
• Book recommendation introduction to model theory
• Estimating Probability Density for Sample
• Understanding the Amanda Knox, Guilty Verdict for Slander
• How to underline several empty lines
• Is the barrier to entry for mathematics research increasing, and is it at risk of becoming less accessible in the future?
• Does Japanese advertises selling something with full price?
• What is the difference in meaning between the two sentences?
• Why does SQL-Server Management Studio change "Execute Query" into "Save Results"?
• How is this function's assembly implementing the conditional?
• How to typeset commutative diagrams
• When I move the bones and they bend, they can't bend where they can do it clearly
• Death in the saddle
• Accumulated charge in conductors
• How can I hang heavy bikes under a thick wooden shelf?
• Dispute cancellation fees by 3rd-party airline booking
• Calculation of centrifugal liquid propellant injectors
• How often does systemd journal collect/read logs from sources
• is it correct to say "push the table by its far edge"?

• Java Arrays
• Java Strings
• Java Collection
• Java 8 Tutorial
• Java Multithreading
• Java Exception Handling
• Java Programs
• Java Project
• Java Collections Interview
• Java Interview Questions
• Spring Boot

Switch Statements in Java

• Jump Statements in Java
• Java if statement with Examples
• Break statement in Java
• Enhancements for Switch Statement in Java 13
• Pattern Matching for Switch in Java
• String in Switch Case in Java
• Switch Statement in C#
• Switch Statement in C++
• Switch Statement in C
• JavaScript switch Statement
• Switch Statement in Go
• PHP switch Statement
• Switch statement in Programming
• Nested switch statement in C++
• Switch case statement in Octave GNU
• Nested Switch Statements in Objective-C
• Swift - Switch Statement
• VBA Switch Statement
• How to write a switch statement in JavaScript?

The switch statement in Java is a multi-way branch statement. In simple words, the Java switch statement executes one statement from multiple conditions.

It is like an if-else-if ladder statement. It provides an easy way to dispatch execution to different parts of code based on the value of the expression. The expression can be a byte , short , char , or int primitive data type. It tests the equality of variables against multiple values.

Note: Java switch expression must be of byte, short, int, long(with its Wrapper type), enums and string. Beginning with JDK7, it also works with enumerated types ( Enums in java), the String class, and Wrapper classes.

Size Printer Example

Some Important Rules for Java Switch Statements

• There can be any number of cases just imposing condition check but remember duplicate case/s values are not allowed.
• The value for a case must be of the same data type as the variable in the switch.
• The value for a case must be constant or literal. Variables are not allowed.
• The break statement is used inside the switch to terminate a statement sequence.
• The break statement is optional. If omitted, execution will continue on into the next case.
• The default statement is optional and can appear anywhere inside the switch block. In case, if it is not at the end, then a break statement must be kept after the default statement to omit the execution of the next case statement.

Flowchart of Switch-Case Statement 

This flowchart shows the control flow and working of switch statements:

Note: Java switch statement is a fall through statement that means it executes all statements if break keyword is not used, so it is highly essential to use break keyword inside each case.  

Example: Finding Day

Consider the following Java program, it declares an int named day whose value represents a day(1-7). The code displays the name of the day, based on the value of the day, using the switch statement.

break in switch case Statements

A break statement is optional. If we omit the break, execution will continue into the next case. 

It is sometimes desirable to have multiple cases without “ break ” statements between them. For instance, let us consider the updated version of the above program, it also displays whether a day is a weekday or a weekend day.

Switch statement program without multiple breaks

Java Nested Switch Statements

We can use a switch as part of the statement sequence of an outer switch. This is called a nested switch . Since a switch statement defines its block, no conflicts arise between the case constants in the inner switch and those in the outer switch.

Nested Switch Statement

Java Enum in Switch Statement

Enumerations (enums) are a powerful and clear way to represent a fixed set of named constants in Java. 

Enums are used in Switch statements due to their type safety and readability.

Use of Enum in Switch

default statement in Java Switch Case

default case in the Switch case specifies what code to run if no case matches.

It is preferred to write the default case at the end of all possible cases, but it can be written at any place in switch statements.

Writing default in the middle of switch statements:

Writing default in starting of switch statements

Case label variations

Case label and switch arguments can be a constant expression. The switch argument can be a variable expression.

Using variable switch arguement.

A case label cannot be a variable or variable expression. It must be a constant expression.

Java Wrapper in Switch Statements

Java provides four wrapper classes to use: Integer, Short, Byte, and Long in switch statements.

Java Wrapper in switch case.

Regardless of its placement, the default case only gets executed if none of the other case conditions are met. So, putting it at the beginning, middle, or end doesn’t change the core logic (unless you’re using a less common technique called fall-through).

Example: In this code we will identify the weekday through (1-7) numbers.

Read More: Usage of Enum and Switch Keyword in Java String in Switch Case in Java Java Tutorial 

To practice Java switch statements you can visit the page: Java Switch Case statement Practice

Switch statements in Java are control flow structures, that allow you to execute certain block of code based on the value of a single expression. They can be considered as an alternative to if-else-if statements in programming.

Java Switch Statements- FAQs

How to use switch statements in java.

To use switch statement in Java, you can use the following syntax: switch (expression) {    case value1:        // code to execute if expression equals value1        break;    case value2:        // code to execute if expression equals value2        break;    // … more cases    default:        // code to execute if none of the above cases match }  

Can we pass null to a switch

No, you can not pass NULL to a switch statement as they require constant expression in its case.

Can you return to a switch statement

No, switch statements build a control flow in the program, so it can not go back after exiting a switch case.

Please Login to comment...

Similar reads, improve your coding skills with practice.

What kind of Experience do you want to share?

Java Tutorial

Java methods, java classes, java file handling, java how to's, java reference, java examples, java switch, java switch statements.

Instead of writing many if..else statements, you can use the switch statement.

The switch statement selects one of many code blocks to be executed:

This is how it works:

• The switch expression is evaluated once.
• The value of the expression is compared with the values of each case .
• If there is a match, the associated block of code is executed.
• The break and default keywords are optional, and will be described later in this chapter

The example below uses the weekday number to calculate the weekday name:

Try it Yourself »

The break Keyword

When Java reaches a break keyword, it breaks out of the switch block.

This will stop the execution of more code and case testing inside the block.

When a match is found, and the job is done, it's time for a break. There is no need for more testing.

A break can save a lot of execution time because it "ignores" the execution of all the rest of the code in the switch block.

Advertisement

The default Keyword

The default keyword specifies some code to run if there is no case match:

Note that if the default statement is used as the last statement in a switch block, it does not need a break.

Test Yourself With Exercises

Insert the missing parts to complete the following switch statement.

Start the Exercise

COLOR PICKER

Contact Sales

If you want to use W3Schools services as an educational institution, team or enterprise, send us an e-mail: [email protected]

Report Error

If you want to report an error, or if you want to make a suggestion, send us an e-mail: [email protected]

Top Tutorials

Top references, top examples, get certified.

• Manage Cookies
• Working Groups
• Marketplace
• Planet Eclipse
• Report a Bug
• Mailing Lists
• Documentation
• Getting Started / Support
• How to Contribute
• IDE and Tools
• Newcomer Forum

Participate

Eclipse IDE

Breadcrumbs

• Eclipse Wiki

Java17/Examples

Notice: this wiki is now read only and edits are no longer possible. please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/wiki-shutdown-plan for the plan..

• View source

This is an informal page listing examples of features that are implemented by the Java 17 Support, which can be installed from the Marketplace . You are welcome to try out these examples. If you find bugs, please file a bug after checking for a duplicate entry here

Watch out for additional examples being added soon.

• Sealed Classes is a standard features in Java 17.
• Restore Always-Strict Floating-Point Semantics is a standard features in Java 17.
• Pattern Matching for switch is preview feature in Java 17. They are not enabled by default and can by enabled using --enable-preview .
• In Eclipse, --enable-preview can be enabled from the Preferences. It is implicitly added while launching a java program if the feature has been enabled for the project/workspace.

This page was last modified 04:14, 31 August 2021 by Eclipsepedia anonymous user Unnamed Poltroon .

Back to the top

Java 17 Interview Questions and Answers

A curated set of interview questions and answers on Java 17.

1. What is the Records in Java?

Records is a new language feature introduced in Java 14 and finalized in Java 16. A record is a special type of class in Java allows us to define classes that act as transparent carriers for immutable data. Records can be used to replace traditional POJOs, which are often verbose and require a lot of boilerplate code.

This is how we can define the records

The fields of a record are implicitly final, which means that once a record instance is created, the data it contains cannot be changed.

Records provides several built-in methods for common operations such as equals() , hashCode() , and toString() . Like a regular class, these methods can be extended to provide custom implementation.

Records allow you to define a Compact constructor which omits the parameter list, assuming the same parameters as the record components. Within this constructor, you can include validation or normalization logic for the fields.

Records are ideal for creating simple data-carrier classes, such as DTOs (Data Transfer Objects), value objects in domain-driven design, tuples, and more. Records are serializable by default, provided that all their components are serializable.

A record declaration does not have an extends clause, so it is not possible to explicitly declare a direct superclass type, even Record. However, a record can implement interfaces, so you can use them polymorphically.

2. What are Sealed Classes in Java 17?

Sealed classes are a new language feature introduced in Java 17 as part of JEP 409. They provide a way to restrict the subclasses that can extend a class or implement an interface. This feature is useful to create more robust and maintainable code and to define a closed hierarchy of types.

Sealed Classes allow you to specify a limited set of subclasses that can extend a given class or implement an interface.

This is how we can declare a sealed class in Java

The permits clause is used to specify the allowed subclasses for type Shape .

Since the compiler knows all the possible subtypes of a sealed class, it will prevent any other class except Circle , Square or Rectangle to extend the Shape class.

3. How does the pattern matching for instanceof work in Java 17?

Pattern Matching for instanceof in Java 17 enhances the instanceof operator and eliminates the need of type casting and checking.

Traditional approach

With pattern matching for instanceof

As you can notice, it makes the code more concise but also enhances readability and reduces the possibility of errors, such as incorrect casting.

4. How does the Pattern matching for the switch work?

Pattern Matching for switch is introduced as a preview feature in Java 17. This feature extends the switch expression and switch statement to allow pattern matching in case labels. Pattern Matching for switch aims to make code more readable and safe, especially when dealing with type testing and casting.

Please note, the Pattern Matching for switch is still in preview and not yet a finalized.

The Java Tutorials have been written for JDK 8. Examples and practices described in this page don't take advantage of improvements introduced in later releases and might use technology no longer available. See Java Language Changes for a summary of updated language features in Java SE 9 and subsequent releases. See JDK Release Notes for information about new features, enhancements, and removed or deprecated options for all JDK releases.

The switch Statement

Unlike if-then and if-then-else statements, the switch statement can have a number of possible execution paths. A switch works with the byte , short , char , and int primitive data types. It also works with enumerated types (discussed in Enum Types ), the String class, and a few special classes that wrap certain primitive types: Character , Byte , Short , and Integer (discussed in Numbers and Strings ).

The following code example, SwitchDemo , declares an int named month whose value represents a month. The code displays the name of the month, based on the value of month , using the switch statement.

In this case, August is printed to standard output.

The body of a switch statement is known as a switch block . A statement in the switch block can be labeled with one or more case or default labels. The switch statement evaluates its expression, then executes all statements that follow the matching case label.

You could also display the name of the month with if-then-else statements:

Deciding whether to use if-then-else statements or a switch statement is based on readability and the expression that the statement is testing. An if-then-else statement can test expressions based on ranges of values or conditions, whereas a switch statement tests expressions based only on a single integer, enumerated value, or String object.

Another point of interest is the break statement. Each break statement terminates the enclosing switch statement. Control flow continues with the first statement following the switch block. The break statements are necessary because without them, statements in switch blocks fall through : All statements after the matching case label are executed in sequence, regardless of the expression of subsequent case labels, until a break statement is encountered. The program SwitchDemoFallThrough shows statements in a switch block that fall through. The program displays the month corresponding to the integer month and the months that follow in the year:

This is the output from the code:

Technically, the final break is not required because flow falls out of the switch statement. Using a break is recommended so that modifying the code is easier and less error prone. The default section handles all values that are not explicitly handled by one of the case sections.

The following code example, SwitchDemo2 , shows how a statement can have multiple case labels. The code example calculates the number of days in a particular month:

Using Strings in switch Statements

In Java SE 7 and later, you can use a String object in the switch statement's expression. The following code example, StringSwitchDemo , displays the number of the month based on the value of the String named month :

The output from this code is 8 .

The String in the switch expression is compared with the expressions associated with each case label as if the String.equals method were being used. In order for the StringSwitchDemo example to accept any month regardless of case, month is converted to lowercase (with the toLowerCase method), and all the strings associated with the case labels are in lowercase.

Note : This example checks if the expression in the switch statement is null . Ensure that the expression in any switch statement is not null to prevent a NullPointerException from being thrown.

About Oracle | Contact Us | Legal Notices | Terms of Use | Your Privacy Rights

Copyright © 1995, 2022 Oracle and/or its affiliates. All rights reserved.

Get notified in your email when a new post is published to this blog

Visual Studio Blog

The official source of product insight from the Visual Studio Engineering Team

Giving our Azure marketplace images a makeover

Get Hands-On with Visual Studio and Azure: Live at Microsoft HQ this August!

Introducing the Revamped Visual Studio Resource Explorer

A modern Extension Manager has arrived with Visual Studio 17.10

VisualStudio.Extensibility 17.10: Debug your extensions with the Diagnostics Explorer

Developing cloud-native apps with .NET Aspire and Visual Studio

First preview of Visual Studio 2022 v17.11

Maximizing joy and minimizing toil with great developer experiences

Visual Studio 2022 17.10 and GitHub Copilot: Your Coding Partner for Faster and Smarter Development

Improve your code quality with GitHub Copilot in Visual Studio