-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Registering a deserializer changes behavior of serialization #2032
Comments
The underlying issue seems to be the one fixed by #1787. You could probably work around this by writing a Note that I am not a member of this project. |
It seems like that is indeed related to that PR. TypeAdapterFactory is a good enough workaround for the time being. It's a shame apparently nobody has looked at that PR though, this would be nice to fix. |
I'm looking into whether we can merge #1787. |
Gson version
2.8.9
Java / Android version
Java SE 17 (OpenJDK)
Used tools
Description
Serialisation behaviour changes based on whether a custom deserialiser is set or not. More specifically, my objects are not serialised in their entirety if a custom deserialiser is provided.
Here is a case to illustrate:
Creating a
Foo
object, assigning itsa
field tonew B()
ornew C()
results in the intuitive behaviour when serialising theFoo
object:However, when a custom deserialiser for
A
is set usingregisterTypeAdapter
, this changes toExpected behavior
I expect the behaviour to stay the same, whether a custom deserialiser is registered or not.
Actual behavior
The behaviour changes and fields of sub classes are omitted in the result.
Reproduction steps
The above class can be used to reproduce this behaviour.
Exception stack trace
/
Additional notes
This issue seems similar to #1599 , however I am not satisfied with the answer provided there. If the intent behind this behaviour was to be able to guarantee that any serialised object can be deserialised again, why does
caseOne
work although the result can obviously not be deserialised using Gson defaults anymore?I am also aware that using
registerTypeHierarchyAdapter
instead "fixes" the problem. However I don't consider this a fix because it changes the entire semantics of the custom deserialiser. For instance, I can't use the deserialisation context anymore to delegate deserialisation. E.g.context.deserialize(something, B.class)
doesn't work anymore because it's recursive.The text was updated successfully, but these errors were encountered: