Java 10 Is Coming!
CodeFX Weekly #42 — 3rd of November 2017
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
Here's a specific proposal, with commentary, and two questions. Summary: This is a time-based scheme, similar to…
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:
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
The third improvement, a
matches expression, has two important differences compared to
- it is an expression, meaning it not only returns a value (like
returnin there) but is actually evaluated to one (like the ternary operator
... ? ... : ...)
- there is no fall-through
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
- sealed types
Read the JEP for more details.
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
Recurring challenges when running on Java 9
- Encapsulation of internal APIs
- Mending split packages
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
Migration and modularization strategies
- Migration strategies
- Modularization strategies
- Making JARs modular
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
Java's much-awaited "Project Jigsaw" is finally here! Java 9 will include a built-in modularity framework, and The Java…
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 static, and
exports ... to has been ready for a long time. All that's left to cover is reflection (including layers) and
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:
- 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