[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...