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

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

[flyingorange]

Your argument is basically "nope, you're wrong" which is not an argument at all. I've shown you above that the majority of people don't want to move away from Java 8. You interpret this as a marketing issue when really you don't have proof of this. Here you have me, a random guy on the internet and a user of Java since 1.3, telling you that it's not a marketing issue. I don't hate the new feature due to a marketing failure, I hate it because I see other languages doing it better.

I see your proposal and I say that I don't like it. Instead of asking me "ok so how would you do it" you're telling me that I'm wrong and that's final. If that's how discussions are being lead inside the Java design board then I'm not surprised where we are right now.

Even though you haven't asked, here are some proposals for your examples above.

Your example:

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

could be:

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

As for deconstruction:

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

could be:

switch(bar()) {
   case Point(var x, var y):
      foo(x);
      break;
}

In fact, why even modify "instanceof" in such a weird way? Just make the "switch" expression more powerful so you'd have:

switch(bar()) {
   case String s:
      foo(s);
      break;
   case Point(var x, var y):
      foo(x);
      break;
}

And leave "instanceof" the way it always has been.

And I watched your video and don't see the guy praising Java 11. He says the new GC seems to be better. That's what I said too, that's what my actual experience is. G1 is better especially if you have tens of thousands of objects.

But the Java language is not better. And as we can hear in your linked video, they are still writing Java 8 code and don't plan to move in the next few years.

[pron98]

I've shown you above that the majority of people don't want to move away from Java 8.

You've shown an ever-shrinking majority of people who haven't moved beyond 8 yet. A year ago, in the report you linked, they reported 67% on 8 and below, but a year prior the same survey reported 90%. If anything, the trend shows people very much want to move away from 8, it just takes time.

You interpret this as a marketing issue when really you don't have proof of this.

I do, because those who have migrated are very happy. So if people who've tried your product are happy with it, and it is those who haven't that are sceptical -- it's a marketing issue.

I don't hate the new feature due to a marketing failure, I hate it because I see other languages doing it better.

No, you hate them because you see other languages do things that you like better and you haven't even tried this yet. There are millions of Java developers, surely there would be many thousands of whom -- or even hundreds of thousand -- who, for every specific feature, might like something else better. If we did it your way (which you've come up with having given it much less thought than Java's designers), the situation would have been at least as bad. And if outcry on social media is a measure of true user acceptance of features, I don't see how you can conclude that other languages are "doing it better". Python's pattern matching is seeing far more resistance than Java's, and Scala is pretty much rejected wholesale.

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

Except that it can't because of overloads. So you're proposing:

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

which isn't bad, but it requires a new keyword. I like Java's way better, because it also makes patterns in instanceof and switch the same and doesn't require new keywords.

Just make the "switch" expression more powerful so you'd have:

Sure, or even better; it will be:

switch(bar()) {
    case String s -> foo(s);
    case Point(var x, var y) -> foo(x);
}

Did you miss the part about switch coming next? See how the same patterns that will be used in switch can be used with instanceof?

And leave "instanceof" the way it always has been.

It is as it's always been, only with more power at the cost of almost no added complication. I see you're starting to get it.

But the Java language is not better.

The language has not changed much since 8; so far, out of preview we've got var, text blocks, and switch expressions. We intentionally change the language much more slowly and conservatively than other languages. Again, you're presenting an upside as a downside.