Java record pattern matching in JDK 19

Interested in your enthusiasm on this front. If (x instanceof String s) was demonstrated at the JavaOne announcing Java 9. The process is proceeding and visible, but finally getting things so long desired and so long available in other languages isn’t supporting much notion of improved pace. Visibility, yes.

Don't be mistaken, Typescript do not has proper pattern matching support, The proposal is far from being adopted https://github.com/tc39/proposal-pattern-matching

> Related, Typescript is the only language I know of that through flow analysis does not require you to redefine the variable. E.g. you can do something like

This is called smart casting and is widely used in Kotlin

There are some edge cases because of which this had to be done, I think. For example calling static methods via the instance variables, the actual method called would be the static type of the variable at compile time and not the actual type at runtime:

    public static void main(String[] args) {
        Parent instance = new Child();

        if (instance instanceof Child p) {
            instance.print(); // prints Parent
            p.print(); // prints Child
        }
    }

    static class Parent {
        static void print() {
            System.out.println("Parent");
        }
    }

    static class Child extends Parent {
        static void print() {
            System.out.println("Child");
        }
    }

Refinement typing (the TS way) is relatively common in type systems that sit on top of dynamic languages because basically they have no choice. Binding to a new variable, however, is a heck of a lot easier to analyse so tends to be done in languages that don’t need to implement refinement typing.

A couple of interesting exceptions: explicit interfaces make it impractical in C#, and there’s a project called liquid Haskell that adds refinement typing on top of an already strong type system.

In my compilers class, this is how we did static downcasting for the toy language we created (I think it was called Oat?). I think it's clever, but I find that I prefer mechanisms that rebind the variable for clarity purposes. It's super easy IMO to accidentally gloss over something as being just a regular if statement rather than something that's actually statically changing the type of the variable compared to having different syntax than just a regular conditional. I also tend to prefer being able to look at a variable's usage and then look back to the time it was initialized and know that it's still the same type; having the type change only within a given scope without any explicit binding seems like something I'd mess up a lot, especially when reviewing code I didn't write myself.

Kotlin does that as well, and it's a JVM language.

Some of this is a consequence of how typescript works - it carries any structural constraints it can find forward in an advisory capacity, because it is somewhat decoupled from the quite-dynamic runtime behavior of the javascript engine.

It isn't even block-based scoping in the flow analysis above - if in your block there was the code foo = 1; the typescript engine would then expect that foo will behave like a Number at runtime.

I haven't dived in deep enough, but I suspect foo could even have different structural type information within the same expression, e.g. a ternary (typeof foo === 'string') ? something(foo) : somethingelse(foo)

> All the other languages I know of, like this proposal for Java, require the variable to be redefined.

can you give a few examples? This makes no sense to me and I've touched quite a few ecosystems in my time. Maybe I am misunderstanding but my current understanding makes this seem not realistic

That’s not dataflow analysis. It looks like a cast similar to something like in C# ie: if (foo is string as foo) where the “as foo” scoped variable is implicit. It’s basically implicitly redefining the variable with limited scope. Type guards are a slick feature but it is just an expression match and some syntactic sugar. Even user defined type guards in typescript have to be explicitly declared as such.

This would be more an example of CFA.

  const a = “string”;
  if (typeof v === a)

The Typescript way would only work for local variables in Java. Since another thread might update a field between the instanceof check and the use of the field.

Kotlin is the same as typescript.

Java 14 does have something similar

https://openjdk.java.net/jeps/305

Mypy (Python) does this as well. VSCode and PyCharm provide typehints after

   if isinstance(foo, str):
        # code

And of course, Haskell has equivalent too:

    case eqT @a @String of
      Just Refl -> ...

Dart also does this.

Pattern matching is a key feature of functional programming languages; it predates Java by 20 years and remains widely used today. See https://en.wikipedia.org/wiki/ML_(programming_language)

For some examples relating to business logic, see https://docs.microsoft.com/en-us/dotnet/csharp/fundamentals/...

Lots of compilers are written in functional languages and use pattern matching for traversing abstract syntax trees, dispatching on the node type. The OO way to do this is to put all logic relating to a particular class in the class itself. The functional approach is to put all logic for a given method/function in one place and handle all the different types. They are two different philosophies both with different tradeoffs, and which is best depends on the type of program you're writing. But it's nice for a language to support both, so you can pick and choose which approach is best for a given problem.

It shows the majority of its strength in switch statements. You can mostly just use the instanceof for a one line destructuring of a compound object into its constituents. The corresponding rust statement is the `if let` or `if case let` if you are more of a swift fan. Generally you would use it with sum types which were previously extremely nasty to work with in Java but are more useful now with sealed classes.

The pattern shows up a lot with result and option types but you can do it any other time where a tagged union makes sense. The classic way to do a tagged union in Java was just a personal taste amongst bad options: tagging interface and instanceof on implementations or an encapsulating class that will return null (or throw an exception) if the gets are called for the types which aren't encapsulated.

If in your career you never needed to enumerate cases that required different data in each case and you couldn't see how binding those requirements into an invariant via the type system was helpful then you probably won't use these new features either. Some people thought it was helpful but the boilerplate cost was too high so wouldn't do it in practice (I am in this category).

Edit: you could also make tagged unions more type safe with callbacks, but then implementing a closure to pull the value out of the callback was just annoying.

Because there are scenarios where pattern matching (or instanceof) is the better and more ergonomic thing to use. One obvious example I can think of is event handling.

If anything, this is _not_ something JS devs are asking for, but rather devs using functional languages.

"...look something messy like Scala", I feel bad you feel this way as Scala is an incredibly powerful and elegant language.

It's ironic because you're throwing shade at Javascript when JS developers are doing the same thing against Typescript. Fearing what you don't know or understand under the guise that change is bad or things are "good enough".

I wish they had better examples, so here is one. Suppose you are making a scene graph, and you want to have a visitor and run code based on the type of the nodes in the graph. Well, consider two approaches. The first approach is to use a bunch of ifs and instanceof, but this isn't clean and it is fragile. The second approach is to make an interface that has all the types listed under a handler (void handle(Type1 t), void handle(Type2 t), ...) and then write some boiler plate code to do the dispatch.

This feature aims at the conciseness of first model (instanceof) with the safety of the second approach (i.e. all types are handled).

I would love this feature for my project! ( https://www.adama-platform.com ) since I use Java to implement a programming language.

The sealed interface, final implementation case is an interesting one to inspect. Now you can, for example, write a parser with a fixed set of tokens and write switches that exhaustively handle every token. You now get compile time guarantees.

I've never been a fan of Java due to the GC and the boilerplate and runtime overhead (time but also space) that come with it. But I've always had respect for it because it felt so minimal and consistent in its own way, bulky but solid kinda like a BMW car.

Now that functional stuff and instanceof fluff is something else. I don't like it either.

100% agree. Using 'instance of' in Java is a terrible anti-pattern, same as trying to do pattern matching. You should lift that code into instance methods and let the runtime pick the right implementation.

Highly compositional design patterns in Java. When you have a fairly large set of custom types that are hierarchically structued in nature, it can be quite useful.

In most standard IT applications it may be less common. I've seen it used fairly well in scientific applications. There are of course other ways of approaching working with and acting on wide taxonomies of objects that could exist but this is one of them.

> If you are using instanceof in a normal java program

In applications yes, but instanceof is heavily used if you write frameworks.

And as someone else has mentioned, the more functional style java you write the more use you start to make of instanceof

I kinda feel the same. Modern Java is written like some Python/JS Mashup. Its one reason old code bases are a huge mess because code is written in many different styles.

This doesn't take anything away, it just adds extra convenience and flexibility.

instanceof is but one possible use case. Arguably the most useful part of pattern matching is inside switch expressions, and there is an equivalence between the Visitor pattern and this, but the latter is much more readable and maintainable. Sure, the visitor pattern is not that often used, but in certain niches that make use of ASTs often it is pretty much a must.

you sound like a Cobol developer I once knew.. RIP

> Another feature, that Java finally adopts, after decades of not adopting it.

Back in 1997, James Gosling published an article that serves as a blueprint to Java's evolution to this day: https://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java... He explained it further, as related by Brian Goetz in the first 20 minutes of this talk: https://www.youtube.com/watch?v=Dq2WQuWVrgQ

In short, Java attempts to be "a wolf in sheep's clothing," with a state-of-the-art, innovative runtime, wrapped in a language that's intentionally conservative. Java the language only adopts features that have already proven themselves as worthwhile elsewhere, and when mainstream programmers are ready for them. We don't always live up to that standard, but we try.

So another way of putting what you said is that this is another feature that has proven itself enough, for long enough, and that's matured enough for Java to adopt it. Many if not most programming language features don't make it to that stage.

The flip side is to examine which features have never made it to Java and probably never will (at least, they're not on our long-term roadmap). Those include, among others, macros, extension methods, first-class properties, and async/await.

What I love about Java though, is that this new syntax is very clear and its intentions are obvious when you're reading someone else's code. It doesn't require you to hold a mountain of context in your head at all times like Swift and Kotlin do. Yes, it's verbose at times. But verbosity is a good property for a programming language because it allows the code to be read and understood with ease outside of an IDE.

> Another feature, that Java finally adopts, after decades of not adopting it

Java has been steadily moving in this direction for quite a few years now. It's tricky business. There's the language proper, and there's the JVM, which are interdependent. Both are aiming to remain backwards compatible. Introducing new major language features is not an easy feat.