Switch Expressions Coming to Java?
A JEP draft has been created with the title, “Switch Expressions for the Java Language.” The current “Summary” states, “Extend the switch
statement so that it can be used as either a statement or an expression, and improve how switch
handles nulls. These will simplify everyday coding, as well as prepare the way for the use of pattern matching in switch
.” There are several promising characteristics of the proposed Java switch
expression in its own right in addition to its enabling of the exciting Pattern Matching JEP (305).
The Java Tutorial defines a Java statement as a “complete unit of execution” that is “roughly equivalent to sentences in natural languages.” It defines a Java expression as “a construct made up of variables, operators, and method invocations … that evaluates to a single value.” The current Java switch
is a statement, but this draft JEP proposes that switch
be supported as an expression as well.
The Switch Expression draft JEP states in its “Motivation” section, “As we prepare to enhance the Java Language to support pattern matching, several irregularities of the existing switch
statement — which have long been an irritation to users — become impediments.” The draft JEP is highly readable and contains interesting discussion points and illustrative code examples of how Java switch
statement is currently often used within other Java constructors to effectively serve as an expression. The JEP draft shows how the proposal to extend switch
to work as an expression in addition to being supported as a statement would improve the readability and maintainability of the code.
Java expressions need to “evaluate to a single value.” The currently proposed switch
expression would allow the break
keyword to serve like a return
in a Java method. A value could be specified following the break
keyword and that value would be “returned” from the switch
expression.
Because a Java expression “evaluates to a single value,” a Java switch
used as an expression would necessarily be required to provide a default value. An interesting twist on this covered in the draft JEP is for enums. The draft JEP states, “… in the case of an enum switch
expression that covers all known cases (and eventually, switch
expressions over sealed types), a default clause can be inserted by the compiler that indicates that the enum definition has changed between compile time and runtime. (This is what developers do by hand today, but having the compiler insert it is both less intrusive and likely to have a more descriptive error message than the ones written by hand.)” I found this particularly interesting because I’ve seen many cases where developers have either not written a “default” for a switch
on the enum because all enum values at that time were covered by case
s or have written a very generic error message. In fact, running into multiple examples of the latter are what finally led me to write my blog post “Log Unexpected Switch Options.”
The draft JEP also covers some proposed enhancements that would benefit both the current switch
statement and the new switch
expression. One of these is the ability to indicate how to handle a null
reference type passed to the switch
statement. Today, for example, if one passes a null
String
to a switch
statement, a NullPointerException
is thrown. With this proposal, the developer could specify a case null
clause. The current proposal would treat any null
not explicitly handled as null
is treated in switch
today (by throwing a NullPointerException
).
A second proposed beneficial feature for both current switch
statement and proposed switch
expression is to allow an individual case
clause to support multiple potential matching values separated by commas. Three values for which the same behavior applies could be specified with a single case
rather than with three case
clauses sharing a single break
.
The “switch expression draft” is still a draft that doesn’t even have a number assigned to it yet and therefore is highly vulnerable to potential changes. Indeed, the proposal has already been discussed in the mailing lists and modified quite a bit, with an example being “Switch expressions — some revisions.” I found one message on the mailing list, “Switching on float/double/long,” to be particularly interesting. This interesting message is full or technical and historical details including background on why today’s switch
statement does not support long
and an interesting analysis provided by “resident floating-point expert” Joe Darcy regarding floating-point comparisons.
David Goldberg’s 1991 article “What Every Computer Scientist Should Know About Floating-Point Arithmetic” is a well-known resource on understanding the complexities of floating-point arithmetic and representation. Darcy provides some interesting insight into some of these concerns and the IEEE 754 floating-point. He writes, “To address some common misunderstandings of floating-point, while it is often recommended to *not* compare floating-point values for equality, it is perfectly well-defined to do such comparisons, it just might not do what you want.” Darcy addresses handling of NaN
, positive zero and negative zero, and positive infinity and negative infinity. An interesting conclusion is that allowing switch
on floating-point numeric type float
could be implemented to really switch on the value provided by Float.floatToIntBits(float).
It appears that there could be some exciting times ahead for Java’s switch
if it is extended so that it can be used as an expression in addition to its current use as a statement. It’s a development that could lead to cleaner code with less room for errors.
Published on Java Code Geeks with permission by Dustin Marx, partner at our JCG program. See the original article here: Switch Expressions Coming to Java? Opinions expressed by Java Code Geeks contributors are their own. |