Switch Expressions And Java EE Modules In Java 11

CodeFX Weekly #53 — 19th of January 2018

Hi everyone,

not much happening these days. I’m mostly working on the reflection chapter, interrupted by nightlong gaming marathons (Stellaris, Blood Bowl). The noteworthy tidbits have to do with Java 11 (scheduled for September 2018).

I send this newsletter out every Friday. Yes, as an actual email. Subscribe!

Switch expression in Java (11?)

For quite some time now, Brian Goetz, Java Language Architect at Oracle, has floated the idea of implementing pattern matching in Java. (In a past weekly I showed some snippets.) Today’s great news is that we’re getting a part of that feature before the rest of it is fully done! (Java’s new release model already pays off — I suspect we’ll see this in Java 11.)

Switch expressions…

Switch expressions are that feature. At the moment switch is "just" a control flow statement, i.e. it only lets you decide which code path to take:

As an expression, the switch block itself could be evaluated to a value. When implementing that, it makes sense to also remove the possibility to fall through because allowing both at the same time would make it hard for developers to spot what's going on. It is also my understanding that fall-through is by now considered to not have been the best default.

Here’s how the snippet from above will (likely) look like in a future Java version:

If you’ve been reading this newsletter for a while now, you will already know most what I just told you. So where’s the big news?

… in Java 11?

Pattern matching is developed in JEP 305, but yesterday a separate JEP 325 for the switch expression was made public. Why? one might ask. My theory is that the new JEP was created to target an earlier Java version than pattern matching as a whole. Also, we are a few weeks after the cut-off point for Java 10, so every new merge ends up in Java 11. Also, wishful thinking.

No Java EE APIs in Java 11

Java 11 will be the first LTS release in the new release model and as I have occasionally conjectured, it will already cut ties with a few things that were intermediary measures in Java 9.

One thing we now know for sure will be gone are the JPMS modules with Java EE APIs that were deprecated in Java 9. JEP 320 wanted to remove them and the corresponding issue got targeted to Java 11 a few days ago.

If you’re using any of the following packages (module names in parenthesis)…

  • javax.activation (java.activation)
  • javax.activity, javax.rmi, javax.rmi.CORBA, org.omg.* (java.corba)
  • javax.transaction (java.transaction)
  • javax.xml.bind.* (java.xml.bind)
  • javax.jws, javax.jws.soap, javax.xml.soap, javax.xml.ws.* (java.xml.ws)
  • javax.annotation (java.xml.ws.annotation)

… then you need to replace them with third-party implementations (check this StackOverflow answer for inspiration).


A longer piece I found quite intriguing was Meat and the H-word.

so long … Nicolai

PS: Don’t forget to subscribe or recommend! :)