Hi all, i'm starting a new project and considering...

# serialization

[tim]

Hi all, i'm starting a new project and considering kotlinx.serialization over jackson which I am using currently. The project is microservices-based so restful and graphql endpoints which have a decent throughput level (1 request per second average). I understand that kotlinx.serialization is nearly 1.0.0 and was curious on anyone else experiences good or bad/would you recommend a move to kotlinx.serial from jackson? Thanks for your thoughts in advance 🙏

[Evan]

are you targeting native?

[tim]

Not currently but its on the roadmap

[tim]

currently targetting jvm

[Evan]

stick with Jackson

[tim]

any specific reason why? Two pros that stick out in my mind, is I've read that kx.serialze is faster than jackson and i like that its part of kotlin itself?

[tim]

i haven't explore gson either ... is that worth considering?

[Evan]

KotlinX and Gson speeds are comparable, both much faster than Jackson. GSON is low overhead. If you’re only targeting the JVM, go with GSON for now and migrate to Kotlinx when it’s more stable

[Evan]

Gson is also a very mature library, you won’t run into build issues or bugs most likely, which have been a big roadblock for me with KotlinX.

However, I’m targeting native, so I am kind of forced into using KotlinX

[tim]

ahh k

[tim]

brilliant thank you for the feedback

[tim]

i'll do exactly that, checkout gson and revisit kotlinx after a few more releases

[Casey Brooks]

GSON is dead, and it doesn’t know anything about Kotlin (and is likely to cause weird issues like non-null properties throwing NPEs). If your models are Kotlin data models, I’d strongly recommend using kotlinx.serialization

[tim]

dead as in no longer maintained?

[Evan]

I’m using Gson with Kotlin data classes in my legacy codebase just fine

[Casey Brooks]

Pretty much. It rarely gets updated, and as @jw so eloquently puts it, it’s “abandonware”. Jackson is the best choice now for Java, and kotlinx.serialization is definitely stable enough for production use. And it has hit 1.0.0 with Kotlin 1.4

[tim]

sadly i can't move to 1.4.0 at the moment... Arrow is a major dependency as there are some issues there with 1.4.0 with ah unknown resolution date 😞

[jw]

Jackson is much faster than both Gson and kotlinx.serialization. If you're seeing the opposite you're doing something wrong. It's also 10x larger.

Gson is unmaintained, yes.

[tim]

okay so it seems like sticking with jackson for the moment is the right call!

[tim]

i'm easily swayed 🙂

[Evan]

if JW says Jackson is faster, then the write up I read comparing Jackson/Gson/KotlinX must be flawed 🙂

[psh]

Just curious - how does moshi compare?

[jw]

It's on par with Gson. Usually faster, sometimes slower. It operates on bytes whereas Gson operates on characters.

[jw]

In benchmarks you'll see people use a String and then decry Moshi is slower. But how often do you start from a string? HTTP? Bytes. Files? Bytes. DB? Bytes. IPC? Bytes.

[Javier]

@jw can you share some benchmarks?

[Vsevolod Tolstopyatov [JB]]

@jw I wonder, do you have a dedicated benchmarks for moshi vs jackson or this performance comparison comes from your experience?

[jw]

Mostly experience, although i've seen a few benchmarks over the years which confirm it. From working on Gson for a few years and then building Moshi we always knew Jackson was way ahead of us in terms of performance since they throw an insane amount of code at the problem. We rationalize it by saying that our slower performance is amortized by streaming over the cost of the I/O which is always an order of magnitude more. So the tradeoff is that we desire a smaller library with a smaller API. 90% of the performance at 10% of the size (roughly).