KTOR-7620 Make Url class @Serializable and JVM Serializable #4421
Conversation
wkornewald
force-pushed
the
url-serializable
branch
from
7c7b289 to
62e380e
Compare
| @Suppress("UNCHECKED_CAST") | ||
| public actual fun <T : Any> JvmSerializerReplacement(serializer: JvmSerializer<T>, value: T): Any = | ||
| DefaultJvmSerializerReplacement(serializer, value) | ||
|
|
||
| @PublishedApi // IMPORTANT: changing the class name would result in serialization incompatibility | ||
| internal class DefaultJvmSerializerReplacement<T : Any>( | ||
| private var serializer: JvmSerializer<T>?, | ||
| private var value: T? | ||
| ) : Externalizable { |
There was a problem hiding this comment.
Should such an API better be integrated as part of the Kotlin stdlib itself or at least in a separate library for reuse in other projects? It could also be useful in kotlinx-datetime: Kotlin/kotlinx-datetime#373
And I'll also add the same code to my open-source lib, too (https://github.com/ensody/ReactiveState-Kotlin).
That's unnecessary duplication in multiple places.
There was a problem hiding this comment.
Regarding JvmSreializable interface, you can vote on this issue:
- KT-48243 Publish
kotlin.io.Serializable
I haven't found any issue proposing multiplatform Externalizable implementation, so feel free to create one!
wkornewald
force-pushed
the
url-serializable
branch
from
62e380e to
8db09e6
Compare
| } | ||
| } | ||
|
|
||
| internal object UrlJvmSerializer : JvmSerializer<Url> { |
There was a problem hiding this comment.
Just an idea: To make this slightly easier to implement one could also add a reusable serializer which utilizes kotlinx-serialization (e.g. using JSON or BSON or CBOR internally).
There was a problem hiding this comment.
I like this idea! Would you like to implement it in this PR or in a separate one?
There was a problem hiding this comment.
A separate one. This should rather happen in kotlinx.serialization, so it's generally reusable.
wkornewald
force-pushed
the
url-serializable
branch
from
8db09e6 to
d217ee0
Compare
osipxd
force-pushed
the
3.1.0-eap
branch
2 times, most recently
from
a65ff10 to
9ae3d49
Compare
wkornewald
force-pushed
the
url-serializable
branch
2 times, most recently
from
6666ecf to
9057d9f
Compare
There was a problem hiding this comment.
Could you tell me why can't we mark it with @serializable from kotlinx.serialization?
This PR is doing that, but that's not enough. On Android many APIs work with anything that's Parcelable/Serializable. Imagine you have some random data class which contains a It's very error-prone and inconvenient to force everyone to check all the attributes of every data class and manually use kotlinx.serialization in many different places to ensure that the data is compatible with the Android API. The better solution is to make all widely used types compatible with For this to be possible, the types that are very commonly used in the UI like |
|
That sounds good; let's mark parent interfaces with the @osipxd, could you also check? |
| } | ||
| } | ||
|
|
||
| internal object UrlJvmSerializer : JvmSerializer<Url> { |
There was a problem hiding this comment.
I like this idea! Would you like to implement it in this PR or in a separate one?
| @Suppress("UNCHECKED_CAST") | ||
| public actual fun <T : Any> JvmSerializerReplacement(serializer: JvmSerializer<T>, value: T): Any = | ||
| DefaultJvmSerializerReplacement(serializer, value) | ||
|
|
||
| @PublishedApi // IMPORTANT: changing the class name would result in serialization incompatibility | ||
| internal class DefaultJvmSerializerReplacement<T : Any>( | ||
| private var serializer: JvmSerializer<T>?, | ||
| private var value: T? | ||
| ) : Externalizable { |
There was a problem hiding this comment.
Regarding JvmSreializable interface, you can vote on this issue:
- KT-48243 Publish
kotlin.io.Serializable
I haven't found any issue proposing multiplatform Externalizable implementation, so feel free to create one!
In our project we had to define our own UrlSerializer. It would be much nicer to have this in the Ktor library itself, so it works out of the box (similar to how Cookie was recently extended). Also, types like Url and Cookie should be java.io.Serializable. Otherwise Android crashes when using those types as e.g. screen arguments. This happens very quickly when Url is used indirectly as part of a data class where we wanted type safety.
wkornewald
force-pushed
the
url-serializable
branch
from
e96bd85 to
3ba2335
Compare
In our project we had to define our own UrlSerializer. It would be much nicer to have this in the Ktor library itself, so it works out of the box (similar to how Cookie was recently extended).
Also, types like Url and Cookie should be java.io.Serializable. Otherwise Android crashes when using those types as e.g. screen arguments. This happens very quickly when Url is used indirectly as part of a data class where we wanted type safety.