Java sealed classes and exhaustive pattern matching

(neilmadden.blog)

53 points | by hnisjafx40 2 hours ago

3 comments

  • armchairhacker 1 hour ago
    Java also has recursive patterns and (maybe still in preview) literal patterns: `switch (x) { case A(B(true, var c)) -> f(c); }`
  • timshel2 54 minutes ago
    Scala punching the air rn
  • Larrikin 1 hour ago
    Java continues to try and catch up to Kotlin https://kotlinlang.org/docs/sealed-classes.html

    I didn't mind Java when the comparisons were to C++, Ruby, and Python. I can not find a reason to go back after Scala (which seemed to fail due to being indiscriminate) and especially Kotlin

    • pron 50 minutes ago
      A hoarder may have much more furniture than I do, but if I buy a sofa it doesn't mean I'm trying to catch up to the hoarder (who has five). Java isn't trying to catch up for the simple reason that we don't want it to have all the features Kotlin does; in fact, we're trying very hard to avoid that (not to mention that we have yet to adopt a single Kotlin feature; our features usually take a different form, even though Kotlin, Java, and many other languages often rely on the same inspiration, which is usually the ML language). That's because some languages aim to be feature-rich while others aim to be more minimal. Both are likely to accumulate features over time, but at very different rates (we'll hold off on features for years until we're satisfied that their value justifies the added complexity to the language, as keeping that relatively low is very important to us).

      If you like a richer language, the Java platform offers you options, but many people prefer smaller languages (the number of Java Platform developers who use the Java language has remained pretty much at a constant ~90% for the past 15 or more years), but we're aware that a non-tiny minority of developers prefer richer languages, and so we accommodate them, too. Either way, 95% of the JDK is runtime (standard library and the JVM) and tooling, and you'll enjoy it regardless of which frontend language you prefer.

      • bmacho 7 minutes ago
        > Both are likely to accumulate features over time, but at very different rates (we'll hold off on features for years until we're satisfied that their value justifies the added complexity to the language, as keeping that relatively low is very important to us).

        This strategy will still navigate Java into a random local optimum like it happened with other languages (that value backward compatibility), just more slowly. The greedy algorithm does that. Even if you do it slowly and you are extra careful that each step indeed betters the language.

    • DarkNova6 49 minutes ago
      What I like about Java is that it is a deliberate late-mover language. It doesn't go for the latest shiny thing but looks at what features have proven themselves in other languages.

      I can't help but to be a little sobered by the promises of Kotlin and C#. They look great on the surface, but once you have more complicated code to work on they tend to show warts quite fast.

      Java is remarkably consistent and really doesn't have any sharp edges. Even with generics and type erasure, I found myself fighting the language semantics in C# way more often than Java.

      • cogman10 37 minutes ago
        I personally enjoy Kotlin. There are potential warts with it, but those exist with other languages.

        That said, Java taking it's time and observing the playing field is a huge benefit. And now that they've been slowly delivering new language features, it's really made it pretty nice flow of powerful well thought out extensions each release. There hasn't been one of the new features that I think missed the mark.

    • jmarlow47 27 minutes ago
      Kotlin feels like it's having an identity crisis. The gap between the two languages continues to decrease. Kotlin is trying to be server-side, Android, but also every other platform (KMP). Feels like everything is brand new and also deprecated at the same time, always moving on to something new.

      Maybe Roman really was the soul and it lost its touch without him?

      I guess in the age of AI it doesn't matter since a few years from now, if you change your mind, you can just ask Jeeves to one-shot rewrite it back to Java.

    • sideeffffect 1 hour ago
      > Java continues to try and catch up to Kotlin

      Does it, really? Java has had pattern matching since 21 (2023). Kotlin still, to this day, the year of our Lord 2026, doesn't...

    • biglyburrito 35 minutes ago
      Java still inexplicably doesn't have first-class support for string interpolation/templates. They were slated to add it in Java 23, but they removed it from the preview and it hasn't been seen since.

      https://www.happycoders.eu/java/string-templates/

      • pjmlp 32 minutes ago
        Because the feedback on how they worked apparently wasn't that positive.

        Also who cares having to use String.format() in the agentic coding age?

        • kbenson 11 minutes ago
          Honestly, I still write a lot of perl, and while interpolation is nice and good to have for simple things, I find myself using sprintf more and more in production code, especially in the cases the examples always show off, such as needing to alter the variable, add two together, etc. I assume those are just shown to illustrate you you can do that, and not imply you should, because commonly using arbitrary code execution within interpolation is something I'd feel compelled to beat out of my coworkers if I encountered it regularly.
    • pjmlp 33 minutes ago
      It is the Java Virtual Machine for a reason.

      Without Google's godfather, Kotlin would be gone for now.

      Kotlin is so great, where is the Kotlin Virtual Machine, showing how Kotlin can stand on its own?

    • pixelstack 11 minutes ago
      Scala*
    • troupo 58 minutes ago
      Of all languages the only one it's trying to catch up to (and in places outran) is C#

      With many others it doesn't compete because it would need a from-scratch rewrite of the runtime (Erlang/Elixir), or a from-scratch redesign of the type system (Rust, perhaps Swift).