[abhayb]

Hard same on the Kotin/Jackson sadness. Gson also has a bunch of issues. Really want to cut my code over to Moshi but haven't worked up the energy for it. Maybe we all just want to wait till Kotlin serialization is production ready?

[ragnese]

Does Gson still force you to write "beans"?

In any case, this project kind of didn't need any auto-magical serialization library, but the promise was reduced boilerplate. Instead, we just got way more complex boilerplate and a damn dependency forcing me to change how I want to write my code.

[abhayb]

Pretty much. I'm all about data classes so the code reads just fine. Definitely less boilerplate than something like JsonObject. But using Gson means non-nullable fields can still be null if the incoming JSON doesn't have them. So you get these "impossible" NPEs. Also, this is more a complaint about the JVM type system but Gson can encode things that it can't decode into which really messes with my mental model.

[ragnese]

My experience has been that there might actually be MORE boilerplate now than when I did ad-hoc translation to/from JsonObject.

inline classes straight-up don't work with Jackson, and probably never will. So for every class that has a field that is an inline class, I have to write a "builder class" that's exactly the same except replacing the inline class with the class it wraps.

Also, @JsonUnwrapped doesn't work with Kotlin. And, of course, doing anything with generics is a complex nightmare with Jackson (because of JVM's type erasure).

Not to mention, all these failures happen at runtime, so you don't even know your class is going to be a problem until you run the code.

The whole thing just sucks and I actually miss the simplicity of translating by hand...