Kotlin data classes can use Java records as their implementation if running on JVM, so it’s not like you have to choose one or the other.
https://kotlinlang.org/docs/jvm-records.html#declare-records...
https://kotlinlang.org/docs/jvm-records.html#declare-records...
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"}
sealed class EitherTest {
data class Left(val abc: Long): EitherTest()
data class Right(val def: String): EitherTest()
}
enum class EitherType { LEFT, RIGHT }
data class EitherTest(val type: EitherType, val abc: Int?, val def: String?)
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?
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.
Being able to use local records is a useful feature in particular in unit tests.
@Test
void testPoints() {
record Point(int x, int y) {}
...
}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.
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.