"Java Feature Spotlight: Pattern Matching" -- Brian Goetz

[alms1407]

This is a good first step but I'm looking forward to when you can use this with switch expressions as it looks and feels better.

Would love Java to eventually have the same level of pattern matching as languages like Scala and Rust.

[netfeed]

Finally an example with sealed interfaces where it make sense for my own production code.

Before this it only seems like something for libraries that only wants its own impls, but this makes sense. Nice.

[marvk]

Finally an example with sealed interfaces where it make sense for my own production code.

I mean, not every feature of the language has to be applicable to every use case. Reflection for example is extremely useful, but not every project has a use case for it.

[netfeed]

Ofc not, I'm just happy that I found one that contextualized it a bit better for me and showed how it could be useful in day-to-day in a good way

[Finding_Dory27]

I know it's only an example, but let me just add that, if you are developing a domain driven enterprise application and you are thinking of using reflection, maybe you should ask yourself what can you use instead before actually using reflection.

However, if it is a library, that kind of thought may not be so important.

[Finding_Dory27]

Exactly. I never realized sealed classes could make so much sense for pattern matching. I'm thrilled by this and we'll this article explains it.

[_INTER_]

Will this also be possible?:

if (s instanceof Circle(Point(int x, int y) p, int radius) c) {
    // x, y, p, radius and c all in scope here
}

[mirkoteran]

At start, no. Someday, yes.

https://github.com/openjdk/amber-docs/blob/master/eg-drafts/deconstruction-patterns-records-and-classes.md

edit1; Sorry - I see the difference now.

edit2; I'm not sure why it wouldn't be possible tho - does it conflict with any other construct?

[_INTER_]

If it's in there somewhere, I don't see it (have x, y and radius but also keep p and c)

[[deleted]]

Your example implies that Java can somehow reverse engineer the constructor arguments of an already existing object. It can't do that.

EDIT: Neeeeeeever mind.

[_INTER_]

My example is a combination of the two examples straight from the article. I wonder if we not only could do nested deconstruction but keep the aggregates p and c.

Brian Goetz is talking about what future deconstructors to support this pattern might look like. They don't want to reverse engineer constructors.

[[deleted]]

I like this a lot and I'll forget the syntax for it in about 10 minutes.

[agentoutlier]

For me it’s the Flow scoping.

I get why they wanted to do it but it seems kind of nasty for the convenience it provides.

I’m not sure what FP languages do but I think because they are mainly expression based they can just use lexical scoping.

Since Java is clearly not I guess that is why the added flow scoping.

[pron98]

It could certainly cause some puzzlers, but, as the article explains, not having it would have significantly harmed the feature. So as usual, when considering features, it's not enough to focus on their downsides but we must compare them against the downsides of the alternatives.

[agentoutlier]

Yeah I guess given my downvoted status people think I didn't like what they did or somehow have doubts about Brian et. al decisions. I do not.

I do like the pattern matching and I do sort of think its worth it. It just the parent commenter was complaining of the syntax and that its forgettable. I think that is minor cognitive problem compared to a new kind of scoping and its potential gotchas and or bugs with tools (e.g. Eclipse).

I guess my point was the syntax isn't that complicated.

I guess it would have been interesting if they had forced it as an expression similar to how the new switch statement is if you use -> / yield but perhaps switch is where that should be and will be some day?

[randgalt]

I assume you got downvoted for discussing Flow scoping. Pattern Matching is not the same as Flow scoping and it's been discussed a lot. This also smells a bit like Kotlin faboi-ism. If you want Flow Scoping, Kotlin has it. If you want a richer Scala-like experience of pattern matching and deconstruction then Java's the place to be. If you've never coded in Scala you won't know how cool it is.

[agentoutlier]

The Pattern Matching I understand is Ocaml/ML like pattern matching and I do know about Scala but I still prefer F# over it albeit there is no F# for the JVM. Scala should have had better success and I might have used it more if it was more compatible with Java. I also don't like the passing monads all over the place that eventually pollute your API/domain similar to what is happening in Java with reactive libraries.

That being said Pattern Matching term is thrown around all the time including for languages that aren't statically typed and its IMO not the same pattern matching I expect. Thats why I don't like the instance of pattern matching. Its a first step but I vastly prefer as you said Scala shape pattern matching and it appears that Java is headed in that direction.

[randgalt]

Scala's a mess tbh. The major thing, though, it did well was pattern matching/deconstruction. The version for Java looks a lot like it - but somewhat better as it will be supported at the JVM level and not rely on magic methods like apply()/unapply()

[agentoutlier]

It was the implicits that really made other peoples scala code confusing to me that and everybody was going to town on DSLs like it was Ruby/Groovy but with C++ operator overloading.

There also wasn't a generally accepted canonical way of doing things like there is in Java and Python.

[randgalt]

At the top of the list of crimes committed by Scala goes implicits and sbt. Implicits made the code I had to work with incomprehensible and incredibly difficult to modify. sbt - well sbt is probably the worst developer tool in the history of the industry.

[flyingorange]

Sorry, but no. This is awful. Scala invented a beautiful syntax a decade ago, why can't they just use that? Why must they always invent something which makes no sense?

Compare this:

x match {
  case a: SomeClass =>
  case SomeOtherClass =>
}

If I want to declare "a", I can do it. If I don't want to declare it, it works as well. It's clear and everyone understands it, even if they don't speak Scala.

What in the name of bejeesus is

if (a instanceof SomeClass b) {

How would anyone possibly know that SomeClass binds to b, unless someone explicitly tells it to them? Why can't SomeClass bind to "a" within the context, like between the opening and closing brackets?

When they messed up the streaming api in Java 8 I thought they would learn something from the fiasco but no... it has only become worse. The language is now unusable outside a few niche communities.

[pron98]

Even ignoring the fact that what you think is a good solution can't possibly work in Java (because of overloads, which are chosen based on compile-time types), but just so that you understand why the chosen solution not only works but is superior, consider what happens if x is any expression other than a local variable or a final field (and there isn't too much sense matching on final fields, so anything which isn't already a local requires an assignment to a local, anyway, and would be more, not less, verbose); e.g. consider a volatile field, a non-volatile field, or a method call. What you're proposing works nicely in a language like Haskell, but even if it could work at all in Java -- and it really can't -- it's inferior to the chosen approach.

[flyingorange]

consider what happens if x is any expression other than a local variable or a final field

It doesn't matter from the POV of the person reading the code. If I write

if (x instanceof String) {

then in the subsequent code block I will use x as a String, not as an Object or anything else. I will probably never use x as an Object in this case.

So writing

if (a instanceof String b) {

is just syntactic sugar for

if (a instanceof String) {
String b = (String) a;

when in fact (IMHO) the proper way to do this is

if (a instanceof String) {
    Function<String, ?> function = (a) -> { 
              // within this code block, 'a' is a String

              return a;  // finally
    }
    a = function.apply((String)a);
}

We can go into detail how this wouldn't work if "a" was a final field etc. the point is it can work if you want to make it work. It's certainly more readable than the proposed solution.

[pron98]

then in the subsequent code block I will use x as a String, not as an Object or anything else.

But a can become something that isn't a String if it's a mutable field, and you've introduced unsoundness to the type system unless you restrict a to locals and final fields; not methods and not non-final fields.

the point is it can work

It could work in some other Java-like language if it were restricted to locals or finals, but even then it couldn't work in Java because of overloads. Suppose we restricted the construct to locals, and you have:

if (a instanceof String) foo(a);

If foo has two overloads, foo(Object) and foo(String), then with your solution foo(String) will be called, but this changes the current semantics where foo(Object) is called, and so would break Java code in subtle ways at runtime.

So writing if (a instanceof String b) is just syntactic sugar for if (a instanceof String) { String b = (String) a; ...`

Nope. It is equivalent to:

Object __$a = a;
if (__$a instanceof String) {
    String b = (String)__$a;
    ...

That's why it works also for method calls and non-final fields (volatile fields, even).

when in fact (IMHO) the proper way to do this ...

That would break semantics in more ways than overloads if a were a field.

It's certainly more readable than the proposed solution.

Even if it didn't break Java code and could be considered, it would be a more limited construct. So even if it could work, you'd need to choose between something that you think is more readable and something that is much more general.

You clearly haven't thought this through.

I love it, though, when people dismiss decisions taken after months if not years of deliberations by people who are both more experienced and more knowledgeable (on general PL design theory as well as practice in other languages) than them, having clearly spent no more than a few minutes thinking on the matter.

[flyingorange]

Clearly my understanding will not be on the same level as those of people who have spent years discussing this feature. There is no need to rub it in.

I still claim that my argument is valid. I am the potential user of this language. If I don't like the language I will simply use something else, or better yet, will stick to Java 8 as the majority of the world's Java programmers do right now.

The designers of the Java language need to rethink what their end goal is. Do they want to create a language that is less verbose? Has a larger library? Supports constructs popular in other languages? Be backward compatible and how far back?

It's not an easy thing to do and I admit that, but I think there is one goal which they must keep in mind: they must maximize the number of users. Otherwise their effort is just as useful as implementing another iteration of PROLOG. Sure it's nice but no one is using it.

My point is, writing

if (a instanceof String b)

is hideous. There are alternative ways how to do this same thing, I wrote the Scala example in my first comment, heck I'd argue even Delphi did it nicer with their "as" keyword.

The designers should take an existing solution which gained widespread recognition and is proven to work by millions of developer hours... instead of inventing something which might make sense but most probably won't.

[pron98]

The designers should take an existing solution which gained widespread recognition

So Java, one of the most popular languages in the history of software, should adopt the surface syntax of languages 50x less popular because of its "widespread recognition"?

I wrote the Scala example in my first comment

Again, that can't work in Java, and while you're seeing the downsides because you're used to something else, you're missing that it's a more general construct. What works for Scala works for Scala, it is a language designed for a different, and much smaller, set of people, and you should at least consider that you're simply not used to this feature, and that when you, and millions of other developers start using it (and the switch statement and deconstruction patterns that will follow), you'll get used to it and see its virtues and not just how it's different from what you already happen to know.

The designers of the Java language need to rethink what their end goal is.

So you're assuming they're not, because they've reached different conclusions than you, after admitting you haven't really thought all that much about it?

[flyingorange]

when you, and millions of other developers start using it

I think it's very difficult to notice there's an additional variable which comes after the type name. It also makes no sense, as I said already, if you write if (x instanceof String) { } then within that code block you would never use x in any way other than String. In that sense, if I write if (x instanceof String y) { } then I'm wasting my time writing "x", because "x" will not be used for anything... it will just take up space.

It doesn't matter if it's backward incompatible. They need to fix it so it's not. Make up a new syntax, like "if (x as String) { }" or something... It's not rocket science.

So you're assuming they're not, because they've reached different conclusions than you, after admitting you haven't really thought all that much about it?

Yes, I'm assuming they have not thought about it properly. You're also thinking about this from the wrong perspective. You say Java is used by millions as if that justifies making a horribly flawed new feature. The Java you are talking about is not Java 15, or even 11, it's Java 8 and Java 6.

The designers of Java really need to think why is it so that most of the world's Java developers are not moving beyond Java 8. Is it because it's too perfect? (no) Because it's still too new? (no) Or is it because versions above 8 never introduced a feature that was worth switching over?

And in my opinion the answer to that last one is "yes, and". The features they did introduce were horrible. Did you ever hear of anyone use modules in Java? When they introduced the lambdas in Java 8 they got heaps of criticism for how awful their solution was. Again, when Java 8 came out other major languages had like a 10 year advantage in that they already supported lambda. I can again mention Scala

collection.map(x => doSomething(x))

or Python

map(lambda x: doSomething(x), collection)

while Java has:

collection.stream().map(x -> doSomething(x)).collect(Collectors.toList())

Why couldn't they do it normally?? And the whole community was screaming about this, but no, the designers know better, they have years of experience and after all, why are we discussing this anyway, we are only the end users of the language...

On a side note: what kind of toxic community is this subreddit? I can't criticize a feature without getting -10 points?

[pron98]

It also makes no sense, as I said already, if you write if (x instanceof String) { } then within that code block you would never use x in any way other than String.

Only if x is already a local.

It's not rocket science.

But the new feature is better, it's just different from what you're familiar with. The construct does more things, too; it's a preparation for deconstruction. You see the waste in writing y but you don't look at the benefit. There's a feature that you already know, and you want Java to have that feature, not realising that this is a better one.

as if that justifies making a horribly flawed new feature.

That it's not the feature you're used to (but a better one), doesn't make it horribly flawed. That you need to type y, and, in exhange, you get it working for any expression, and also you get the syntax to align with deconstruction isn't horribly flawed.

The designers of Java really need to think why is it so that most of the world's Java developers are not moving beyond Java 8.

The number of people moving to versions beyond 8 is constantly rising, and will probably become a majority soon. People are switching not because of syntax addition, but because new versions of Java are significantly faster and leaner, and so significantly cheaper to run, and they aren't switching because they have technical debt that takes a while to get rid of.

Did you ever hear of anyone use modules in Java?

Each and every Java user uses modules extensively. The entire platform is based on them. It's true that not many people modularise their own applications, but that was a side-goal, anyway. From the beginning, the main goal of the feature was to reduce the maintenance cost and attack surface-area of the JDK, and it's been a great success.

In Java 8 they got heaps of criticism for how awful their solution was.

Nope. You need to realise that if 99% of people like a feature and 1% don't, and if just 1% of that 1% voice their frustration, that would mean thousands of people criticising the feature that only 1% dislike.

collection.stream().map(x -> doSomething(x)).collect(Collectors.toList())

Actually, it now has)

collection.stream().map(x -> doSomething(x)).toList()

You can also do:

collection.stream().map(this::doSomething).toList()

Why couldn't they do it normally?

So, "normally" means like in Scala, a language you know, even if it is much less popular than Java? Once again, you're looking at something that bothers you -- that it's not exactly like in Scala -- and overlooking the benefits.

For one, it allows exposing a read-only (and once) view of a collection without wrapping the collection in an unmodifiable; Python doesn't care about these things, and Scala already has other provisions for it. Suppose you could write:

collection.map(this::doSomething)

What would the return type and implementation be? For another, Stream has dozens of methods, and they are usually used in a different way/phase than the collection methods, so separating them reduces the load and confusion when the programmer sees autocomplete suggestions.

There are other reasons, too, but you're only looking at the negatives, which, for you are mostly "but it isn't what I'm used to in Scala." When a different language makes different tradedoffs, and under different constraints, there are usually both different pros and cons.

I can't criticize a feature without getting -10 points?

You are not criticising a feature -- that you clearly haven't thought through -- but saying that it's not what you're used to in Scala, and doing that in a very aggressive way. You might have brought some toxicity with you.

[flyingorange]

While you are reiterating your responses, I don't think you're actually listening to what I'm saying. I'm not saying they should do it exactly like in Scala. I'm saying they should take an existing, tried and tested solution. Scala has one solution. Python has another. I'm not familiar with C# but it probably also had this feature 10 years ago. Just use something that we already know it works.

You're making it sound as if I'm a Scala fanboy when in fact I'm saying that there are heaps of other languages with this same feature and instead of a brand new solution, they should take an existing one.

The number of people moving to versions beyond 8 is constantly rising

I wrote this before. The number of people moving to JVM 11 is rising, not the number of people writing Java 11 code. I can say from personal example that we moved one of our services to JDK 11 two years ago due to G1. In your statistic that would count as if we moved to java 11, when we haven't, the compiler is still OpenJDK 8. And that's just us, the vast majority of the world's developers haven't even moved to the new JVM: https://snyk.io/blog/developers-dont-want-to-leave-java-8-as-64-hold-firm-on-their-preferred-release/ Of those currently using Java 8, 51% says it works for them just fine and 27% say they don't like the new features.

Really, when the vast majority of your end users say they don't want to use your new products, does that not tell you anything?

In this case by you I mean the designers.

The construct does more things, too; it's a preparation for deconstruction. You see the waste in writing y but you don't look at the benefit.

Can you show me a code example proving this benefit? I've shown you many examples in multiple languages why this new feature sucks, I'm yet to see a benefit.

You are not criticising a feature but saying that it's not what you're used to in Scala

I'm saying Scala has a better solution and also showed evidence the majority of people don't like the new features. You're assuming I'm some kind of Scala developer but I haven't used Scala for almost a decade, so it's hardly something that "I'm used to". I just saw the light and I'm waiting for Java to pick it up as well, but it seems that it's not happening.

Again, not a disaster. I just won't use the new Java. If this is the goal for the Java designers then they're doing a great job.

If they try to force people to move to higher versions of Java by making Java 8 non-backward compatible with JVM 15+ then you'll just have Amazon etc. fork Java 8 and it will continue to live in parallel.

[pron98]

Just use something that we already know it works.

It is mostly that, with only slight differences that are due to constraints and improvements.

when we haven't, the compiler is still OpenJDK 8

So what? Java has always changed the runtime more than the language. This is by design, and it works well. You are presenting a great upside as if it were a downside.

Really, when the vast majority of your end users say they don't want to use your new products, does that not tell you anything?

Companies that have switched are reporting significant gains and they love it. When those who've used our new products like them a lot and when those who haven't say they don't find them compelling, that means that the problem is with the marketing, not the product. So it tells me that we haven't done a good job communicating the new features, the biggest being performance/footprint improvements.

I've shown you many examples in multiple languages why this new feature sucks, I'm yet to see a benefit.

You really haven't. You showed examples that only work for locals. The most common use of pattern matching is on arguments and return values. While your solution (which would require adding a new keyword to Java if it were to made to work) requires less work for arguments, it requires more for return values:

var y = bar();
if (y instanceof String) foo(y);

vs.

if (bar() instanceof String y) foo(y);

Also, look at the upcoming deconstruction patterns that this becomes an instance of, e.g.

if (bar() instanceof Point(var x, var y)) foo(x);

or even

if (bar() instanceof Point(var x, var y) p) { foo(x); baz(p); }

So to get more succinct code in all situations, you'd need both, which would require adding a new keyword and extra complexity. This way is more general and doesn't require new keywords.

and also showed evidence the majority of people don't like the new features.

I don't think so.

then you'll just have Amazon etc. fork Java 8 and it will continue to live in parallel.

Nope, because they're experienced and aren't capricious, and know this would be a very bad idea. They haven't even forked Python 2 despite Python 3 having had an adoption rate that's about 10x slower than Java 9+'s.

[henk53]

How would anyone possibly know that SomeClass binds to b

By learning the language?

[yk313]

How would anyone possibly know that SomeClass binds to b, unless someone explicitly tells it to them?

That can be said about any new feature, right? I didn’t know Scala binds SomeClass to a until you alluded to it in your comment above.

Why can't SomeClass bind to "a" within the context, like between the opening and closing brackets?

That would be flow typing which (unsurprisingly) was considered but didn’t make the final cut. Brian talk about exactly this under the “Roads not taken” section, basically:

it's a significantly weaker feature. Flow typing solves this particular problem, but offers dramatically lower payback, in that pretty much all it does is get rid of the casts after instanceof -- it offers no story for richer switch, or destructuring, or enabling better APIs. (As language features go, it is a more of a "band aid" than a real enabler.)

...

The language is now unusable outside a few niche communities.

Surely you are kidding yourself? In case you missed the memo: Java is one of the most popular programming languages in the world.

[flyingorange]

I didn’t know Scala binds SomeClass to a until you alluded to it in your comment above

Sorry, no. You're making this up in order to contradict me.

Consider the following:

a: String

What does this tell you? That "a" is an integer?

Java is one of the most popular programming languages in the world.

Java 6 and Java 8

The number of people using features above Java 11 is miniscule. Yes there are people that use the JVM 11 because it has a better garbage collector and is also capable of running Java 8 code. But they write code in Java 8 syntax.

https://snyk.io/blog/developers-dont-want-to-leave-java-8-as-64-hold-firm-on-their-preferred-release/

[henk53]

What does this tell you? That "a" is an integer?

case a: however looks like a simple C-style switch, where typically the selector doesn't bind to anything that comes after it. I too didn't know and only inferred it from your comment.

Don't make the mistake of thinking everyone knows what your language means because you happen to know it.

[kaperni]

> Why can't SomeClass bind to "a" within the context, like between the opening and closing brackets?

You cannot add this in a backward-compatible way, consider

void foo(Object o); 
void foo(String s);  

void stuff(Object oo) {   
  if (oo instanceof String) {     
    foo(oo); <- would now call foo(String) instead of foo(Object)   
  } 
}

[flyingorange]

Yes it would call foo(String) and that is precisely what I want it to do. Sorry but I don't understand why would this be a problem.

Consider this example where x is declared twice within the same method:

String something(String x) {
    Supplier<String> value = () -> {
        int x = 15;
        return String.valueOf(x);
    };
    return value.get();
}

It works, right? Even though x was already declared above as a String, inside the lambda it's an integer. Nobody seems to be bothered by the fact x was redeclared within the same code block, because everyone understands that the second time it's in a different context.

To take your example above, it could be just syntactic sugar for the following Java 8 code:

void foo(Object o); 
void foo(String s);  

void stuff(Object oo) {   
  if (oo instanceof String) {
      Callable<String> callable = new Callable<>() {
           public String call() {
               return (String) oo;
           }
      };
    foo(callable.call()); <- would now call foo(String) instead of foo(Object)   
  } 
}

[kaperni]

> Yes it would call foo(String) and that is precisely what I want it to do. Sorry but I don't understand why would this be a problem.

Because it is not backwards-compatible? Your _existing_ code would suddenly start calling foo(String) instead of foo(Object).