since we are moving towards using Kotlin more and ...

# android

[raghuramjampala]

since we are moving towards using Kotlin more and are moving towards Kotlin data classes for network requests and responses, does anyone know of any adverse effects of Kotlin data classes and GSON? I’ve read it can break the immutability part of Kotlin, so something can be null when it shouldn’t be because of the use of reflection by GSON

[540grunkspin]

Not sure what you mean. The reflection part can probably set non nullable fields to null but it think that kotlin will crash pretty early on if that happens, this is the case for moshi. If json has null for fields what shouldn't null, according to kotlin, moshi crashes as soon as the field is set. Not sure if this is the same for gson

[gildor]

Gson and Moshi are java-centric libraries and do not respect nullability.
You can use adapter generation library kotshi for Moshi or moshi-kotlin (uses kotlin-reflect), they check nullability.
Don't know such library for Gson except auto-value-gson (but it works only with AutoValue classes, not with Kotlin data classes)
But Kotlin libraries for Json support nullability out of the box. Check #klaxon and kotlinx.serialization #serialization

[louiscad]

If you go down the Moshi path, you should use it with kotshi rather than moshi-kotlin

[Charlie L]

I’ve used Jackson and their kotlin module with Kotlin data class requests & responses. GSON didn’t have sufficient polymorphism support for us

[Charlie L]

typescript-generator is a useful project, if any of your clients are written in Typescripts.

[Paul Woitaschek]

@louiscad @gildor I wouldn't recommend kotshi, just use the codegen of moshi

[gildor]

My message is 2 years old 😬

[Paul Woitaschek]

Oops. How did he dig that post 😄