jackson-module-kotlin VS kotlinx.serialization

Support for inline classes

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

But, it sucked. I was constantly finding bugs related to nullability, around generics, inline/value classes, etc. And it wasn't the typical trivial ones, either. Figuring out that you're calling a Java library and encountering a "platform type" is the least problematic. My biggest struggle came from using libraries that were written in Java first, but then added a Kotlin API on top. So, my code didn't know I was dealing with a platform type and neither did I. Yet they were still broken. Some of them are broken in an unfixable way, such as JacksonXML's Kotlin module: https://github.com/FasterXML/jackson-module-kotlin/issues/479. So many Java libraries rely on reflection even when it's not obvious that they might, so you pretty much can't ever use value classes in Kotlin, including the unsigned number types.

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

Did you include jackson-module-kotlin?

Good API design dictates that you should be flexible as to what you accept and strict about what you serve. Being flexible doesn't really break anything.

Elasticsearch and Opensearch both actually have partial support for JSON5 (comments), which is a nice feature if you want to document e.g. a complex query or mapping choice. It won't return any comments in the response. So it won't break other parsers. Implementing JSON 5 support like this is a valid thing to do for any server. More broad support for this in parsers would be nice.

I'd probably enable this on my own servers if this was possible. I'd need that to be supported in kotlinx.serialization. See discussion on this here: https://github.com/Kotlin/kotlinx.serialization/issues/797

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

Regardless, I followed the documentation to register List for polymorphic serialization and my static code analysis does not seem to be happy with it.

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

This example will not work on a multiplatform project. you are using gson, gson runs only on jvm, you should use https://github.com/Kotlin/kotlinx.serialization for the json parsing

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

Fun fact, kotlinx.serialization had a release just recently which makes it come with some bundled proguard rules to make this experience easier. Yes you'll still have issues if you're using things via reflection and try to serialize things that proguard deemed unused and removed them, but it's a step forward https://github.com/Kotlin/kotlinx.serialization/releases/tag/v1.5.0-RC

Kotlin Serialization