I am new to
kotlin but a veteran of
scala. The former has impressed me so far. But at this moment I am working through a head scratcher - that the
data class does not implement
Serializable. How a class with that name could expected to <em>not</em> be routinely expected to be used in that manner eludes me.
What are the technical challenge(s) that precluded that support? I'm interested because i'd like to create a wrapper. It seems that the expectation is to always provide a
serializer() ? That is cumbersome and actually
kotlinx.serialization is not working for me yet - even after some effort.
It is a bit unclear from the question if you mean
java.io.Serializable (based on the analogy with Scala and "implement") or
kotlinx.serialization.Serializable (based on the second paragraph and discussion in the comments).
First, for the Java one:
I think the way you should phrase it is: why do data classes not implement
Serializable <em>by default</em>? You can always add
: Serializable if you want.
Then you can note this isn't the only place where Kotlin requires you to be more explicit than Scala. For another data class example, you need to mark properties by
var where Scala assumes
val by default. And for non-data classes, Scala allows you to use non-
val constructor parameters inside the class effectively promoting them to
private val where Kotlin doesn't.
Serializable in particular:
It would privilege Java serialization which has bad reputation (as mentioned in the comments already).</li> <li>
Serializable isn't usable in cross-platform (or just Kotlin/JS or Kotlin/Native) projects. Maybe data classes could only be serializable on JVM, but it would be an unnecessary mismatch between platforms.
case classes implement
Serializable even if they have non-
Serializable properties and will throw if you actually try to serialize them.
In the common case of multiple case classes extending a trait, if you forget to make the trait
extends Product with Serializable type inference often gives ugly types.
For Kotlin Serialization, the answer is even simpler: you don't want a basic language feature like data classes to depend on an experimental and immature library. I wouldn't be surprised if data classes do become
@Serializable by default when it "graduates" like coroutines did in 1.3.