jackson-module-kotlin VS kotlinx.serialization

Jackson's learning curve is a lot lower (it helps that it's older and more popular, so there's more guides online), and it has a lot more options. However, Jackson doesn't fully support Kotlin, for example: value classes. For this reason, I would avoid it.

strictNullCheck option in the Kotlin module doesn't cover non-object-field situations at all. https://github.com/FasterXML/jackson-module-kotlin/issues/479

You should add Jackson Module Kotlin in your project. After that, you can't specify a type of object explicitly.

Not really, you just need to handle some standard types and have a good extension mechanism to let the user implement factories. That library having built in support for UUID and datetime is probably a bit much, I'd prefer a plugin like https://github.com/FasterXML/jackson-module-kotlin

There is a bug at this very moment that makes it literally impossible to deserialize [1, 2, 3, null] into a List with Jackson's Kotlin module. Yes- even if you set KotlinModule(strictNullChecks = true). It's just broken. (Here's the link: https://github.com/FasterXML/jackson-module-kotlin/issues/479)

Got you, thanks. I didn’t mean to sound offensive - a better wording would be that they don’t seem to prioritize this part, at least based on https://github.com/FasterXML/jackson-module-kotlin/issues/199, which has one abandoned branch from a 3rd party and a couple of comments from from maintainers.

If you use Jackson, don't forget to include the Kotlin extensions https://github.com/FasterXML/jackson-module-kotlin

Have you tried this:? https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/serializers.md

It might be possible with a value class

I think kotlinx.serialization might come close, but looks like custom Encoders and Decoders are still experimental.

This is the issue to +1 https://github.com/Kotlin/kotlinx.serialization/issues/1931

Kotlin Serialization

Kotlin Serialization is also a newer option, but doesn't have as much traction.

``` see the docs

It makes sense for some use cases but the vast majority of use cases, parsing overhead is simply not a concern. Mobile phones are fast, networks have plenty of bandwidth (and the savings are marginal), parsers are pretty good.

But done right, binary protocols are sometimes worth the marginal savings they provide. We switched over one of our APIs to use CBOR instead of json. It's a search API that we hit a lot and I wanted to cut down on the bytesize of the responses a little. The savings are not that impressive. But I'll take 10% when i can get it.

Otherwise, this was a pretty simple change. We use kotlinx serialization in a multi-platform library. Basically, all we did is configure it to use CBOR instead of json. https://github.com/Kotlin/kotlinx.serialization/blob/master/... Half hour job. Haven't looked at it since; just works. It supports protobuf as well but it looked like more hassle to set up so we went with CBOR instead.

I'm very much with you on kotlinx.serialization's pain points. And unfortunately, there just doesn't seem to be much of a willingness to fix them. They seem very tied to their polymorphic/contextual serialization model, despite all the problems it causes.