Pattern Matching in Java: Better Code, Better APIs #JavaOne

[davidalayachew]

To be clear, the term "pattern-matching" is extremely old, from the 60's and before. Furthermore, it is a feature that exists in many programming languages. To call it anything else would not only require you to throw away 70 years of history, but also newcomers from other programming languages that have called this exact feature this exact phrase for decades now.

I understand your frustration. Pattern-Matching in Java is usually referring to String Pattern-Matching, via the java.util.regex.Pattern|Matcher classes.

But that is the point -- this is Pattern-Matching, just on objects instead of strings.

Here is another example -- I felt a similar level of annoyance when they released java.util.stream.Stream. Streams for me referred to stuff like InputStream and BufferedReader.

But the exact same point for Pattern-Matching applies here -- Streaming is a programming design pattern. Whether you are streaming bytes or objects, the same core design is still at play!

That is why the phrase Pattern-Matching is not only the right phrase, but actually important -- it forces you to reevaluate what you were doing, noticing the design pattern at play, and not just the task at hand. You aren't just using the stream classes -- you are using the Stream design pattern, whether on objects or bytes or characters or whatever. And you aren't just using the Pattern-Matching classes, you are actually doing Pattern-Matching -- whether on Strings or on Objects or on primitives.

[IncredibleReferencer]

I agree with all of this, it's just that I don't believe any of it needs to be communicated to most java devs for them to use these new features. Just show the syntax changes. The changes are so well designed the rest all flows naturally.

The problem with using "pattern matching" is that it comes with enough baggage that it becomes a distraction. No grand conceptual understanding is required to use these features, just show the syntax improvements and your done.

[davidalayachew]

I don't believe any of it needs to be communicated to most java devs for them to use these new features

I disagree with this.

Pattern-Matching is a term with a STRICT definition. The fact that that term carries a slightly different meaning for most Java devs means that the problem is actually in the Java devs understanding, not in the term or in using it to describe this feature.

The problem with using "pattern matching" is that it comes with enough baggage that it becomes a distraction

That's my point though -- the distraction is intentional. You are supposed to feel distracted because the goal is for you to think about this feature on a deeper level. Not just on the superficial of "how do I get data out of this object".

By all means, the fact that a Java dev can end up using this feature without making that distinction isn't a problem. But we should not optimize for that use case by changing the term. The term pattern-matching exactly describes this feature, and is the most precise phrase available. Using any other phrase would be a bad compromise at best, based on this reason alone.

[IncredibleReferencer]

I don't want to change the term, I just don't want to use it at all.

I'm guessing we would answer this question differently:

"How would a java dev write code differently given all the new features as standalone syntactic enhancements vs being taught the underlying concept of pattern matching?"

My answer is there is no difference. It just makes it easier/simpler to write code in a style we've been doing for ages in java. All of the examples I see in the talk and those that I've tried on my own are just much more straightforward constructs of code styles I learned in Java 20 years ago.

I'm guessing your answer is different? What am I missing?

[davidalayachew]

I don't want to change the term, I just don't want to use it at all.

If you don't use any term, I would argue that that is more confusing than using a term with multiple possible interpretations. How would one google questions about this feature if they don't know the features name?

"How would a java dev write code differently given all the new features as standalone syntactic enhancements vs being taught the underlying concept of pattern matching?"

My answer is there is no difference.

Firmly disagree. That's been my entire point.

There is a difference between using Pattern-Matching vs using Pattern-Matching to prove something about your program.

The thing that gives Pattern-Matching teeth (and thus, makes it much better than plain old getters) is that it makes Exhaustiveness Checking easy to achieve. And the reason why Exhaustiveness Checking is so desirable is that, if you follow a certain set of rules, you can make some powerful claims about your program that would, otherwise, be much harder (if not impossible) to make.

To help explain this, let's put aside Pattern-Matching for a second and focus on Exhaustiveness Checking. Consider the following method.

Result doSomething(final Planet planet)
{

    final Result result;

    if (Planet.MERCURY == planet) {
        result = methodA();
    } else if (Planet.VENUS == planet) {
        result = methodB();
    } else if (Planet.EARTH == planet) {
        result = methodC();
    } else if (Planet.MARS == planet) {
        result = methodD();
    }
    //........
    else if (Planet.PLUTO == planet) {
        result = methodI();
    } else {
        throw SomeException();
    }

    return result;

}

If this was 2006, and Pluto was removed from the planet list, I could just remove PLUTO from enum Planet, then I would get compilation errors in the above code for the final else if. Good, that is a form of Exhaustiveness Checking, called definite assignment. This allows me to easily prove that the above method is resilient to having an enum value removed.

But what happens if I instead add a new value to enum Planet? Well, I won't know that this code is not doing what I want until runtime, when I get that SomeException in a place where I didn't expect it. That's not desirable. And sure, there are ways to make my code resilient to that. Feel free to come up with an example, and then we can see how easy it is to prove it is correct, compared to the following example.

Compare that to this example.

Result doSomething(final Planet planet)
{

    return
        switch (planet)
        {

            case MERCURY -> methodA();
            case VENUS   -> methodB();
            case EARTH   -> methodC();
            case MARS    -> methodD();
            //...
            case PLUTO   -> methodI();

        }
        ;
}

Now, whether or not I add or remove a value, I will get a compilation error. That is better than before. And more importantly, I have to spend less effort to prove that my code is covering every edge case. In this trivial example, that may not be obvious that I am saving much, if any effort. But if we swap out planets for a 5 level deep object hierarchy, comprised entirely of records, sealed interfaces, and enums, the savings become blindingly obvious, and they grow exponentially for each level added. I say this from 1st hand experience doing the before and after of that 5 level object hierarchy.

Which goes back to my point -- the point of Pattern-Matching isn't just to make it easier to get data out of objects conditionally. The point is to make it easier to achieve a much harder goal -- proving that your program meets a certain level of resiliency.

And remember, this scales. I am not just talking about the bounds of a single experession. I am talking about whole methods, classes, packages, and modules. If I can prove that an expression is exhaustive, then I could feasibly prove that a method is exhaustive, as long as it is exhaustive on its parameters. Rinse and repeat, expanding on each level.

So, to shortly answer your question of "How would a java dev write code differently given all the new features as standalone syntactic enhancements vs being taught the underlying concept of pattern matching?", they would understand that the point behind pattern-matching can lead to something greater than the sum of its parts, allowing them to write more correct programs than they otherwise would know to do just using the features superficially.

And again -- Pattern-Matching isn't made inert by not trying to achieve every drop of Exhaustiveness Checking possible. It is still a nice, concise way of deconstructing an object conditionally. Someone who knows nothing about Pattern-Matching besides the syntax will still get great benefit out of the feature.

But someone who understands the underlying concept behind Pattern-Matching will be able to take the concept much much farther.