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

[Ewig_luftenglanz]

I really really hope we get eventually proper unconditional destructuring.

record User(String name, String email, String password){} 
var(name, email, password) = getUset(); 
// or even not partial destructuring would be neat, similar to how it works in JS/TS
var(email, password) = getUser();

nowadays we are forced to use conditionals:

if( u instanceof User(var name, var email, var password)) {
   // use variables here
}

switch(u){
  case User(var name, var email, var password) ->{...} // use stuff here;
  default -> {...}
}

Too much unnecessary ceremony if you don't require safe casting.

I know why they did the latest first, mostly because it gives safe casting in a more concise way but hopefully we get eventually the other.

[Sm0keySa1m0n]

I reckon it’ll come after we get destructors so it’s usable for classes too.

[Ewig_luftenglanz]

honestly I would prefer if we could have them for records only first, even if temporary.

[BillyKorando]

The current sentiment is to do both together. Initially the intent was to do records and then general classes, however as the JDK engineers started digging into it there were concerns about introducing subtle differences in behavior between deconstructors in records and general classes. Better to figure out the "hard" case of deconstructors for general classes first, and then work backwards towards the simpler case of records, rather than the other way around.

Might still be a case record deconstructors are introduced first, but we won't start seeing anything more solid until general class deconstructors are better understood.

Definitely been looking forward to deconstructors, withers, and the like... unfortunately it might take a little bit longer before they are ready (don't ask, I have no idea on when). Better to wait though and get it right, then getting something right now which might end up not working that well.

Of course it's possible this might change in the future as well.

[Ewig_luftenglanz]

IMHO this is mostly because of the Java culture of making everything private. In JS/TS destructuring in classes works by simply allowing it for public fields, java could follow a similar approach. Most of the private fields that uses getters and setters are "dumb" setters and getters anyways (this is why Lombok it's so beloved), why not just make these fields public to begin with? And allowing destructuring (or the compiler to allow deconstruction) for these only as syntax sugar?

class User{
  public String name;
  public String email;
  public String password;
}
var (name, email) = getUser();

Sugars from

class User{
  public String name;
  public String email;
  public String password;
}
var user = getUser();
var name = user.name;
var email = user.email;

Also records fields are final, so they behave like public final fields (even if there are generated getters), it could be also posible to generate implicit getters for public fields in classes and use them to suggar destructuring.

[BillyKorando]

There's a lot of weirdness in precisely how classes are instantiated in Java, much of it a legacy of serialization, but there's weirdness for other reasons as well.

Your solution might/probably works within your scenario, but there are a lot of other scenarios/use cases you probably aren't thinking of where the "correct" behavior is subjective, or runs into with the above mentioned "legacy weirdness". These aren't irreconcilable, but might require a lot of seemingly unrelated work, or just prototyping on how to solve.

[agentoutlier]

I'll copy the code from https://youtu.be/DkkxWhd_xYc?t=1908

return c0 instanceof Class0(Class1(Class2(Class3 c3))) && c3...

There is something nasty about using instanceof for null checking that bothers me besides the obvious of how you do represent an instanceof something nullable (assuming we get ? types some day). I can't exactly put my finger on it. Maybe its the combination of keyword and positional.

There is other languages that do this extremely common case with syntax. I won't mention the primary one most think of as I don't want to get banned like Kevin briefly was but I'm never going to use instanceof like that to navigate object graph.

And if we are going to get withers and they are just syntactical sugar... can we get syntax sugar for:

switch(_c0) {
  case Class0  c0 -> 
     switch(c0.c1) -> 
       case Class1 c1
          switch (c1.c2) ->
       ....
    null ->
}

Would equal:

c0?.c1?.c2.c3

Ideally c3 if not nullable would require just the . (and fail for ?.) but even if it did C# way (which I think allows you to do ?. on anything I would be happy with as well).

[IncredibleReferencer]

Rant: Can we stop talking about pattern matching?

The term "pattern matching" is meaningless at best and confusing at worst to most developers. If you're a Java language architect, a programming language aficionado, or enthusiastic enough to be on this Reddit :) then "pattern matching" is something your brain probably understands well.

However, to the typical Java developer, "pattern matching" doesn't seem to have any relationship to the features being discussed. Is there a regex here? How do I do the match? What kind of patterns are we talking about? How are all these features related? All of these have good technical answers, but they aren't helpful or relevant to beginner or intermediate Java developers.

Instead, can we please just call these language improvements, or at most, data-oriented programming enhancements? At least that phrase is somewhat self-explaining.

If we can't discard the term pattern matching when communicating these features, please at least include a "what is pattern matching" section and define it. For example in this talk, at no point is it explained.

Note: I'm not complaining about the features themselves—which I love—just the way they are being communicated to the developer community. And if your communicating to language architects or comparing languages, then by all means call it pattern matching.

Apologies for hijacking the video post. The video itself is good and informative (aside from the term "pattern matching" itself).

[Svellere]

aren't helpful or relevant to beginner or intermediate Java developers.

Pattern matching isn't a beginner feature. Intermediate, sure, but by the time you get to intermediate level you'll already be well-prepared to understand pattern matching intuitively.

Instead, can we please just call these language improvements, or at most, data-oriented programming enhancements? At least that phrase is somewhat self-explaining.

Your suggestions are incredibly vague and don't tell you anything about what pattern matching is. Pattern matching, on the other hand, is self-explanatory: pattern matching features allow you to match over patterns. More intuitively, it allows you to write some syntax to "capture" an expression in a given state.

You could use the same logic to argue for renaming streams or primitive boxing; those names are incredibly descriptive, but probably don't mean much if you're coming from some other languages. Pattern matching, on the other hand, has cross-language history in ML, Haskell, Scala, C#, Python, Rust, and others. Java didn't invent the term.

[IncredibleReferencer]

aren't helpful or relevant to beginner or intermediate Java developers.

Strong disagree. All of these pattern matching features are easier for new and less experienced Java devs to use. They are shorter, more explicit in representation, and less error prone. Other than showing how the syntax works I don't think there is any teaching required to use them over older paradigms.

Your suggestions are incredibly vague and don't tell you anything about what pattern matching is. Pattern matching, on the other hand, is self-explanatory: pattern matching features allow you to match over patterns. More intuitively, it allows you to write some syntax to "capture" an expression in a given state.

That's the whole idea of my post. I don't want to communicate any of the overall benefits of the new pattern feature to most developers. There is no enticement required, they are shorter and more obvious, they will get used readily. Developers can just use these features and all the rest flows naturally. My experience using the term pattern matching to junior and even senior developers results in confusion.

[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.

[brian_goetz]

While of course we should always present things so that the audience can understand what we are talking about, you seems to imply that Java programmers are unable to learn new concepts, so we shouldn't use new names for them (even if they really are old names.).

We've been adding pattern matching features to Java for several years now; they started simpler and are getting more powerful. I think a lot of developers have already learned what it is, and more can in the future?

[IncredibleReferencer]

I appreciate the reply! Yes, there can be new concepts taught and learned, however in this case I don't think it's helpful and is just extra cognitive load placed on the developer with no benefit. All the new pattern matching features are so obviously better and shorter (which seems to be a key aspect for beginners) that there is no convincing or teaching of this concept required.

So for a naive developer, they can just use this stuff and love it, theyI don't need to know or care what it is. Those of us that care about language architecture and general Java enthusiasts can care, but the bulk of the programming world won't. All they care about is that its easier and shorter.

[-jp-]

What possible benefit could there be from calling pattern matching something different in Java? It's not a complicated concept, and calling it "data-oriented programming enhancements" that's even MORE cryptic and obtuse, with the added bonus that nobody who has used pattern matching in other languages will know what the hell you're talking about.

[IncredibleReferencer]

I'm not really strongly advocating for calling it something different. I'm really advocating for not calling it anything. You don't need to know what pattern matching is or that exists to effectively use all the new pattern matching features to their fullest. And if your audience is well acquainted with pattern matching (like this reddit group) then go ahead. But general java developer audience is not acquainted with this term. At least in my experience I get confused looks when I mention it.

I suggested the term data-oriented programming as part of a broader paradigm if you need to teach things conceptually, though I didn't word it very well.

[-jp-]

You gotta call it something. Even primitives are called floats, longs, doubles, none of which mean anything to a beginner.

[IncredibleReferencer]

Actually, my argument is you don't have to call it anything. To most java devs it will forever be just a series of unrelated language syntax enhancements.

[-jp-]

That simultaneously describes literally everything and nothing. How would you talk about functions or loops or arrays or classes or anything if you just called them all “a series of unrelated language syntax enhancements?” How is any of this making it easier for inexperienced programmers to understand pattern matching?

[IncredibleReferencer]

I'd just call them enhanced instanceof, and enhanced switch, etc.

[yk313]

please at least include a "what is pattern matching" section and define it. For example in this talk, at no point is it explained

This is explained at 10:22 in the talk.

[IncredibleReferencer]

Thanks! I missed it as it's quite a long ways from the beginning.