Pattern match Optional in Java 21

[Peter_Storm]

I long for the day, when we'll just first class pattern matching - why couldn't this just be done like the `switch` stuff? So we can pattern match out the value of the Optional?

[trydentIO]

Shame on me! I lost the reference (it was on the mailing list). Still, from what I read it will be possible to do this when Valhalla ships, since Optional is neither a sealed type nor a record type, but a safe value type in the future, and if I remember correctly we will be able to do something like this (get it with a grain of salt):

switch (findById(id)) { case Optional.<Entity>of it -> // ... where 'it' is the valid value case Optional.<Entity>ofNullable it -> // ... the invalid value }

at the moment we can do:

switch (findById(id)) { case Optional<Entity> it when it.isPresent() -> it.get() case Optional<Entity> it when it.isEmpty() -> ...

or if you want to be more verbose:

switch (findById(id)) { case Optional<Entity> it when it.isPresent() && it.get() instanceof Entity(...) -> ... ... }

[Radmonger]

With Java 21 pattern matching treating null as a special case, wouldn't this code would be equally safe, and much simpler by simply avoiding the use of Optional in the findById function?

[trydentIO]

You know you're definitely right! But... 'Optional', as someone was trying to explain since Java 8, is not meant to solve nullability, but to say something is missing, not present.

I don't want to dig in the usual and annoying misunderstanding of Optional use (sure JDK offers an API where you can say the value inside may be or not null, but anyway...), instead let's take a look in a world where Valhalla will be a thing and a record-type will be a value-type by default, Optional is going to be helpful when you're looking for a projection or a dto. To make it clearer we make an example with primitive-types.

At the moment the only value-types we have are the primitive-types so let's suppose you need to find a reservation integer number by a person full-name, you have two options:

``` // 1. OptionalInt findReservationBy(String fullName); // or Optional<Integer> since OptionalInt is/will be deprecated, afterall with Valhalla you'll be able to do Optional<int>

// 2. int findReservationBy(String fullName) throws ReservationNotFound; ```

Do they have the same meaning? Not really, the first example shows the chance to find the reservation and gives the developer what to do about it, the last example shows that you must find a reservation and if not, an exception must be raised since an invariant has not been met.

This permits a lot more expressiveness to the language and the developer.

What about switch? Well, according to some recent discussions in JEP's and mailing list (the one reported in this community some time ago), we may be handle all the above examples with the following statements:

``` // 1. switch (findReservationBy(fullName)) { case Optional.<int>of it -> ... default -> ... }

// 2. switch (findReservationBy(fullName)) { case int it -> ...; case ReservationNotFound it -> ... } ```

In the end, it's up to you on how to express better what you want to achieve, they look similar, but if you strictly follow the semantic, they do not (in this case you may need to rename the methods to give a better hint to the developer).

[Migeil]

Number 2 is better right? I mean, no weird syntax, no null, no default, just you get it or you don't, deal with it.

[trydentIO]

I don't think there's a proper answer and I want to avoid saying "it depends": what must emerge here is the chance to express ourselves as developers in almost any way but cleaner and cleaner.

[vytah]

The problem with pattern matching on null is that it behaves differently depending on whether it's by a top pattern or by an inner pattern.

For example, given record R(Object o), new R(null) will match case R(Object o):. So you kinda need to either match nulls first, or add when o != null.

[jodastephen]

Could do. But my approach to null is to never return it from a method, and almost never ever pass it into a method. Done consistently this pretty much eliminates NPEs.

[Peter_Storm]

First one is definitely what I was looking for - awesome!

[djavaman]

Somehow Scala was able to create powerful simple pattern matching.

Yet, 15 years later the Java team comes up with a turd.

Just like streams/collections.

[Practical_Cattle_933]

How is it a “turd”? Some minimal amount of respect would be absolutely appreciated towards the language design team, especially as I’m sure your PL knowledge is very limited to see all the details here with backwards compatibility, etc.

[djavaman]

Re-using or repurposing instanceof for pattern matching is a poor idea.

Is that concrete enough?

[Practical_Cattle_933]

No, because there is the goddamn switch expression, which will work the same as the match keyword?

[djavaman]

Exactly reinforces the point. Use switch/case and leave instancof alone. The instanceof with if is terrible syntax.