Skip to content
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

Gson serializes anonymous inner class instance as "null" #2059

Closed
jakub-bochenski opened this issue Jan 20, 2022 · 5 comments
Closed

Gson serializes anonymous inner class instance as "null" #2059

jakub-bochenski opened this issue Jan 20, 2022 · 5 comments
Labels

Comments

@jakub-bochenski
Copy link

jakub-bochenski commented Jan 20, 2022

Gson version

2.8.9

Java

11

Description

Give a class definition:

  class Links {
      public Map<String, String> discovery;
  }

The result of running this is "null":

new Gson().toJson(new Links() {{
            discovery = Map.of("foo","bar")
            }}),

This result of running this is as expected ({ "discovery": { "foo":"bar" } }):

new Gson().toJson(new Links() {{
            discovery = Map.of("foo","bar")
            }}, 
            Links.class)

Expected behavior

Both outputs should be the same

This is very problematic, it means the serialization will fail unexpectedly and silently when somebody uses an inner class possibly in completely unrelated part of the code.

@jakub-bochenski jakub-bochenski changed the title Gson serializes inner class instance as "null" Gson serializes anonymous inner class instance as "null" Jan 20, 2022
@Marcono1234
Copy link
Collaborator

Gson intentionally does not support serialization of anonymous classes, see #298. However, I (personally) agree that the current behavior is pretty error-prone. Additionally there has been some discussion from the community that this restriction could be lifted. For example if an instance of an anonymous class is serialized and a custom type adapter exists for it (that is, reflection is not used), then serialization could work without any issues, same for serialization and deserialization of local classes.

The whole class exclusion logic, which just reads or writes null is in my opinion a bit questionable, or at least the default class exclusions (such as the one for anonymous classes) should maybe behave differently and thrown an exception instead.

@eamonnmcmanus what do you think?


Note that I am not a member of this project.

@phxism
Copy link

phxism commented Jan 25, 2022

it comes to an error when switch jackson to GSON.so why GSON does not support serializes anonymous inner class

@eamonnmcmanus
Copy link
Member

I haven't looked into this in detail, but it does seem as if the current situation is poor. For example, if I register a TypeAdapterFactory that can serialize and deserialize any class that implements interface Foo, then that should work, even if the class in question is an inner class. If that's not true that seems like a bug.

I see that GsonBuilder has an option disableInnerClassSerialization which is false by default (so inner class serialization is enabled). Does that not work the way it looks as if it should, or is there some other reason that inner class serialization doesn't work?

@eamonnmcmanus
Copy link
Member

To answer my earlier question, Excluder always excludes anonymous classes. As I wrote today on a related issue, that seems overbroad. (I see I rediscovered there what I knew in January of last year.)

@Marcono1234
Copy link
Collaborator

Marcono1234 commented Sep 23, 2023

@eamonnmcmanus, maybe we should close this specific issue here as "not planned" because the example provided by the author uses an anonymous subclass of their custom Links class, and expects that the reflection-based adapter will work for that. Based on the discussion in #1510 (comment) this seems to be a use case we don't want to support for now.
(The question is if Gson should behave differently and for example throw an exception to make troubleshooting easier, but that is a different topic. And as discussed for #2189, this is probably not feasible at the moment.)

Solving #1510 seems more reasonable, so that issue should not be closed, because it is about using custom adapters for anonymous classes.

@eamonnmcmanus eamonnmcmanus closed this as not planned Won't fix, can't repro, duplicate, stale Oct 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants