What do people recommend for parsing JSON these da...

# android

[edward]

What do people recommend for parsing JSON these days?

[ruitzei]

https://github.com/google/gson

https://github.com/square/moshi

2 of the most populars nowadays

[Love Lindström]

https://github.com/Kotlin/kotlinx.serialization if you need multiplatform and better nullability support

[Stuie]

My team uses both Moshi and kotlin-serialization.

[zsmb]

I personally really like Moshi if you're JVM-only, and there's basically only kotlinx if you need multiplatform. Avoid Gson in Kotlin if possible.

I talked about why I like Moshi here https://zsmb.co/talks/say-hi-to-moshi/

[ephemient]

Jackson works on Android too. current project uses Jackson in a few places and kotlinx.serialization in most other cases. if you don't kotlinx.serialization, I would unquestionably recommend Moshi over Gson.

[Casey Brooks]

Gson is mature and stable, but doesn't understand many of the Kotlin constructs like nullability or default parameters, and is mostly abandoned so don't expect it to ever get those features, so I would not recommend it. I also wouldn't recommend Jackson, as it's a huge dependency that is better suited for servers than clients.

Moshi is very popular, and I believe it does work with those Kotlin concepts (I don't use Moshi, personally), but it is still ultimately a JVM library, so if you're interested in multiplatform support in the future, it won't work for that. As others have said, if you aren't locked into Gson yet, you should absolutely prefer Moshi over Gson

#serialization is pretty good and is fully multiplatform-enabled, but it can be a bit tricky to get the serialization format exactly how you need it in some cases. I personally prefer kotlinx.serialization because I am interested in multiplatform usage

[ephemient]

depends on how large your app is - Jackson doesn't make a big impact on size in our case, and is faster than Moshi in our use

[Paul Woitaschek]

As it bypasses the constructor it's a great way to shoot yourself in the foot.
It will also create multiple instances of objects which can then lead to even weirder bugs

[Paul Woitaschek]

where object = kotlin object

[ephemient]

construction is not an issue if you annotate it with @JsonCreator or use jackson-module-kotlin

[ephemient]

singletons are indeed un-singleton-ified, but we've never had any issues with that - empty objects aren't something we have any purpose for in our data model

[ephemient]

in any case, I do think kotlinx.serialization works better with Kotlin than any of the other libraries mentioned here

[therealbluepandabear]

Use Gson.

[ephemient]

do not use Gson. it is abandonware, it has strange quirks, its creators have all moved to Moshi

[therealbluepandabear]

I've used Gson for almost a year with no issues at all for multiple projects. You shouldn't have any issues, no need to overthink things.

[ephemient]

feel free to keep using Java if that's what you want too. but in addition to being maintained, Moshi actually understands Kotlin (default parameters), has a much easier system for type conversions, and parses byte strings faster than Gson. there's no reason to use Gson in a new project.

[ephemient]

kotlinx.serialization, Moshi, and Jackson have different design trade-offs, so which one(s) of those you pick can depend on your needs, but Gson be fully supplanted by Moshi

[Paul Woitaschek]

It's a huge issue with singletons. It will break the when checks (!)

[ephemient]

I can understand that being a problem but (at least for the use case I'm familiar with, working with an API) when will you ever be serializing or deserializing a singleton? it's zero bits of information, might as well leave it out…