Java 10 Is Coming!

CodeFX Weekly #42 — 3rd of November 2017

Hi everyone,

I spent today traveling to Kiev for JavaDay, where I will give two presentations on Java 9. The newsletter is hence a little short, but it covers both Java 9 and 10. (Yes, 10! Read on!)

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

Pattern matching in Java 10

As promised, Mark Reinhold took in the feedback on the new Java version-scheme and made a concrete suggestion. He not only heard the clamor, though, but listened, and his plan is, in summary, to increase the $major portion of the version string with every release, so in 2018 we'll see Java 10 and 11.

Proposal: Newer version-string scheme for the Java SE Platform and the JDK

Talking about Java 10, as far as I know the only feature that is already targeted for the new version is a first step towards pattern matching (JEP 305):

[This is wrong, pattern matching is not (yet?) targeted for Java 10! It’s still an interesting topic, though, so I’ll leave the section here.]

As an initial target, we aim to support constant patterns and type-test patterms with bindings in the switch statement and in a new matches expression.

Pattern matching is essentially a more powerful switch and the mentioned "constant patterns" are exactly the labels you know, which test whether the variable has a specific constant value. Type-test patterns look as follows:

The case Integer i labels test whether obj is an Integer and, if so, casts it to Integer i, so you can use that variable as an Integer instead of as an Object.

The third improvement, a matches expression, has two important differences compared to switch:

• it is an expression, meaning it not only returns a value (like if with return in there) but is actually evaluated to one (like the ternary operator ... ? ... : ...)
• there is no fall-through

With a matches expression (and a mostly made-up syntax) the example above could look as follows:

Not only does this save us from break-ing out of each branch, it also tells the compiler that we need a value, so if not all cases are covered (e.g. when the default branch is missing), it can discover that. Neat.

Note that this is just the first step towards more powerful pattern matching. Future goals are:

• deconstruction patterns
• nested patterns
• switch as expression
• sealed types

Read the JEP for more details.

JEP 305: Pattern Matching

The Java Module System

My book on the Java module system has seen some churn lately. The second (of three) reviews taught me that people don’t like long chapters. Well, too bad for them, right? It’s not like arbitrarily cutting chapters in half helps anyone.

True, it doesn’t, and after putting my ruffled feathers back in order, I was willing to look for another chapter structure by finding new connections and distinctions and reorganizing content according to them, shuffling some stuff around.

Originally, I planned to have two chapters covering what to do with existing applications: one for compatibility problems (ch. 6) and another for incremental modularization (ch. 7). Unfortunately both clocked in at about 50 pages, which apparently is a big no-no.

So I had to spread the content across three or four chapters. But how? Both chapters mostly consisted of technical details, but each ended with a section putting the pieces together and formulating strategies based on them. Splitting a chapter into two and having such a “big picture section” in one of them but covering both would be insane. A nightmarish abomination with limbs growing from its head, constantly screaming from the agony of its very existence.

Yes, I feel strongly about structure.

But in the end I found a way. First thing I realized was that both sections on strategies (one for migration, one for modularization) could go into a new “Strategies” chapter (new ch. 9). With that on the table, I found something else from the modularization chapter that would make a good fit for the new one.

And regarding the compatibility problems that were way too many for one chapter, I realized that I could scratch another itch: Some of them only have to be solved during a migration (like dependencies on Java EE modules), but others might actually rear their head even long after a migration between application modules (namely the use of internal APIs and split packages). This made it easy to split chapter 6 into 6 and 7.

So there you go, the new chapter structure of part 2, “Migration and Modularization”:

Compatibility challenges when moving to Java 9

• Working with Java EE modules
• Casting to URLClasLoader
• Runtime image directory layout
• Selecting, replacing, and extending the platform
• The little things that make big things fail
• Summary

Recurring challenges when running on Java 9

• Encapsulation of internal APIs
• Mending split packages
• Summary

Incremental modularization of existing projects

• Why migration is even an option
• Unnamed modules — A.k.a. the class path
• Automatic modules — JARs on the module path
• Summary

Migration and modularization strategies

• Migration strategies
• Modularization strategies
• Making JARs modular
• Summary

The early access version was updated a few days ago and now contains every last juicy word from those four chapters.

Manning | The Java Module System

Small aside: As much as I like writing in Asciidoc, its limited capabilities really hurt me here. There seems to be no way to reference an anchor (a clickable link like “6.2” in “see section 6.2”) in a way that deduces the section number — instead I have to count it out manually. In a reshuffling like this, that of course breaks and has to be fixed manually throughout the entire book. Not fun.

With that done, the book is slowly crawling towards being feature complete. I just finished chapter 10 on services and chapter 11 on requires transitive, requires static, and exports ... to has been ready for a long time. All that's left to cover is reflection (including layers) and jlink.

I hope I’m done with that by December 31st, so the book can go in production in January and finally be done 10 to 12 weeks later. Surely took long enough.

Project of the week: Vavr

If you can’t wait to pattern match in Java or need more power than the current proposal, check out Vavr:

Vavr core is a functional library for Java 8+. It helps to reduce the amount of code and to increase the robustness. A first step towards functional programming is to start thinking in immutable values. Vavr provides immutable collections and the necessary functions and control structures to operate on these values. The results are beautiful and just work.

Here’s how to perform the match above:

Shots

• If The World Was Created By A Programmer
• foggy traffic lights
• Why The Cops Won’t Help You When You’re Getting Stabbed
• Bitcoin energy Consumption

so long … Nicolai

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

Photo by Denisse Leon on Unsplash