gson

gson uses reflection to serialize types, including standard library types, which are not guaranteed to have the same fields from one release to another. Presumably the people who write the jdk realized this potential source of bugs and tried to prevent it from happening, meaning fewer ambiguities about what changes are breaking at the expense of breaking gson (and probably others). see: https://github.com/google/gson/issues/1216

Automatic serialization is not the devil, overly forgiving automatic serialization is the devil. I use JSON serialization libs all the time in Scala which properly support optional vs required fields. For Java devs, Gson has bad required/optional support [0] but Jackson does have it for creator properties [1]. It is important to qualify statements like your initial one to include the specific situation which it is bad instead of using a broad brush. 0 - https://github.com/google/gson/issues/61 1 - http://static.javadoc.io/com.fasterxml.jackson.core/jackson-...

I've run into similar issues and one such always seems to stick in my head - A few years back some Samsung and HTC devices shipped with a very buggy version of GSON causing deserialization errors on these devices. You can see the actual gson issue here: https://github.com/google/gson/issues/255 The solution was to rename the package name using a tool called jarjar (https://code.google.com/p/jarjar/) and then things would work just fine. Was kind of a pain to maintain this library in sync with the updates of GSON, but eventually we were able to abandon support for these devices once the company felt the impact was low based upon the stats in the Android Platform Versions - http://developer.android.com/about/dashboards/index.html Android, always keeping us on our toes. :)