This is great news!

I was also kind of surprised to see the article talking about algebraic data types... table stakes for ADTs is sum types and I have missed them considerably in the Java ecosystem.

Kotlin has something like them with sealed classes, although I'm a newcomer to the Kotlin and Spring Boot ecosystem so I don't see explicitly how I make some simple case like JSON

    {"type": "left", "abc": 123}
    {"type": "right", "def": "456"}

turn into some structure like:

    sealed class EitherTest {
        data class Left(val abc: Long): EitherTest()
        data class Right(val def: String): EitherTest()
    }

rather than the hacky version that you have to do in relational databases and Java which don't support such things,

    enum class EitherType { LEFT, RIGHT }
    data class EitherTest(val type: EitherType, val abc: Int?, val def: String?)

Like I’m not saying that there’s no way, I’m sure there’s a way... just that the ecosystem seems so hesitant to embrace sum types that like the above sealed class is widely viewed as a hack and there is no statement about “here is how you actually use sum types for everything in your Spring application with Kotlin.”

Was gonna give the choose-your-own-adventure example of why sum types are handy and how you have to kind of hack around them with inheritance when you don't have them but it occurs to me that anyone who has stuck with this comment this far probably already has some familiarity with this?

Sealed classes are (most likely) going to be in the next version of Java, Java 17: https://openjdk.java.net/jeps/409

You do it like this: https://github.com/Kotlin/kotlinx.serialization/blob/master/...

In traditional Java, you're probably using Jackson for your JSON. You can achieve those sorts of results by specifying the classes and type tags in annotations on an abstract Either class to use Jackson's polymorphic serialization feature.

The point of sealed classes is that you have a known number of possible representations. So you can have `when` blocks that exhaustively check all possibilities. Having an open class hierarchy would not work for that purpose.

this technique works with sealed classes, i’ve done it before. it throws a runtime exception if it can’t identify the discriminant.

The easiest way is with GSON:

https://mkyong.com/java/how-do-convert-java-object-to-from-j...

You would just have to have annotations on the enum names to get the lowercase values in your example json.

I wonder why, unlike a Java record, in Kotlin a data class annotated with @Record can not be local.

Being able to use local records is a useful feature in particular in unit tests.

  @Test
  void testPoints() {
     record Point(int x, int y) {}
     ...
  }

I don't see the point; you're not testing code that depends on Point, as it's local, so `x to y` (i.e. `Pair(x, y)`) would work just as well.

If there's a particular language feature records enable that Kotlin doesn't with ordinary data classes in this case, I'd love to see it.

That misses the point. The strength of records is that the language can build features that are only possible because of records' restrictions. It's not that the bytecode says "I'm a record" - which is all you get if Kotlin compiles a data class to one. @JvmRecord gives you all the limitations with none of the benefits. The annotation only exists for compatibility reasons.

The problem is all of these "benefits" are imaginary right now[1]. You are talking about future possibilities that Java could get due the strong guarantees offered by Java records. That's cool, but I couldn't find in your article (or the JEPs) any such benefit that is available _right now_.

The reality is that Kotlin can build the very same benefits you're talking about as well, in future versions. All the compiler has to do is to restrict these benefits to data classes which only have 'val' members, do not have hidden state and do not use inheritance. In fact, Kotlin is ALREADY enforcing these constraints on a any data class that you annotate with @JvmRecord.

Now, if we're already talking about imaginary future benefits here, Kotlin is also planning to have (immutable by design) value classes when Project Valhalla is ready (you can already have value classes with a single field in Kotlin 1.5).

[1] To be fully honest, Java records themselves are themselves an imaginary feature for the vast majority of Java users until Java 17 comes out, since very few projects would use a non-LTS version. And even then, you can expect years until libraries can start to use them. Kotlin and Lombok data classes can be used right now.

Yeah, and that is a good example of how semantics might change depending on which platform Kotlin code is targeting.