Allow serialization of anonymous classes

[dwilches]

Describe the feature
Gson should allow serialization of anonymous classes, the reason is that the user shouldn't care about the implementation of the code that generates the objects they are using.

For example, this code that only uses Guava and Gson looks fine and users may expect it to print ["a", "b"]:

        System.out.println(gson.toJsonTree(Sets.union(
                ImmutableSet.of("a"),
                ImmutableSet.of("b"))));

But actually, that code prints null, totally unexpected to a user that is not familiar with the implementation of Sets.union (that function returns an instance of an anonymous class).

Additional context

I think this feature is well deserved because of the amount of confusion that has been around the lack of it. If we do a Google search we find several people who were caught by this issue:

• Allow serialization of anonymous and local classes #298
• Anonymous Map initialization does not serialize correctly. #762
• Unable to use GSON to serialize anonymous class javalin/javalin#288
• https://stackoverflow.com/questions/10746278/serializing-anonymous-classes-with-gson
• https://stackoverflow.com/questions/26791752/convert-anonymous-java-object-types-to-json-using-gson
• https://stackoverflow.com/questions/55622921/custom-gson-serializer-for-anonymous-classes

And the list goes on and on.

I think what aggravates the lack of this feature it he way Gson silently serializes those instances to null, which is a source of silent bugs.

NOTE:
Deserialization of anonymous inner classes is problematic, I'm not asking for that to be supported. This feature request deals only with serialization.

Possible workarounds

I've seen suggested workarounds like:

gson.toJsonTree(union, TypeToken<Set<String>>(){}.getType());.

But notice that only works in the most simple of cases, but it doesn't work in cases where we have a Map with values of different anonymous classes:

ImmutableMap.of(
    "key1", Sets.union(...),
    "key2", new HashSet(){},
    "key3", new MyRecord(){}
);

As there is not a single TokenType I can accommodate for that disparity of values and that will behave as expected. Moreover, sometimes the values are not known at compile time (in designing APIs, the values can be anything the user passes to us, and its out of our control).

[inder123]

Very early versions of Gson actually supported inner classes.
What do you expect to happen to the outer class reference? Ignore it silently or serialize it as well?

[dwilches]

Note that the topic of this issue is not inner classes but anonymous classes.

Anyway, ignoring the references to the outer class seems fine (imagine a circular dependency otherwise). Gson's documentation already explicitly mentions the behaviour to fields corresponding to outer classes:

Fields corresponding to the outer classes in inner classes, anonymous classes, and local classes are ignored and not included in serialization or deserialization.

[piegamesde]

If you don't want to implement this, fine, but at least give an exception instead of silently serializing to null. I just lost way too much time debugging some weird NullPointerExceptions until I realized it was due to the use of anonymous classes.

I think deserialization should be possible as an opt-in through the use of custom type adapters.

[al6x]

There should be some option to tell Gson to include the fields of anonymous classes, something like toJson(obj, withAnonymousStuff = true).

[Marcono1234]

Besides general support for serialization of anonymous classes, there are also these special cases for which it would be even more reasonable to allow serialization or deserialization:

• When the user has registered a custom TypeAdapter / TypeAdapterFactory for the type (or a supertype)
• When the user has registered a custom InstanceCreator, and therefore the risk of a NullPointerException after deserialization when accessing the enclosing class does not exist

Personally, I find the proposal mentioned in #1510 (comment) to throw an exception on deserialization quite compelling, but I think it can unfortunately not be easily implemented:

• When implemented with a custom GsonBuilder setting, it might be necessary to differentiate between inner class, anonymous class and local class, and would therefore bloat the API
• When implemented as built-in TypeAdapterFactory which throws the exception on deserialization, the user could not overwrite this behavior by registering a TypeAdapterFactory which delegates to reflection-based deserialization (because delegation would delegate to that throwing adapter factory)
• When implemented with a built-in instance creator (or as part of the internal ConstructorConstructor), it would be somewhat redundant, the proper solution might be to use GsonBuilder.disableJdkUnsafe(). And users could also not disable this behavior / delegate to Unsafe instance creation without a new GsonBuilder setting.
• When implemented with a ReflectionAccessFilter it would not be possible to differentiate between serialization and deserialization

Also, on deserialization trying to detect whether a local or anonymous class uses the enclosing instance does not seem to be possible (until recently, see JDK-8271623), because even when the enclosing instance is not used, the compiler seems to generate a field storing the enclosing instance anyways.

So maybe Gson should just remove restriction for local and anonymous classes, assuming that the users knows what they are doing. This would be backward incompatible, but the question is how many users really rely on Gson ignoring the values for anonymous and local classes.

Users could still achieve the old behavior by specifying an ExclusionStrategy, and as shown above, if users want Gson to throw exceptions, they could use multiple approaches to achieve this.

@eamonnmcmanus, what do you think about dropping this restriction for anonymous and local classes?
(we might need to find out though if there are use cases relying on this behavior)

[eamonnmcmanus]

I'm not terribly motivated to support serializing anonymous classes. It's easy enough to make a named class if you need to serialize it, and I'm concerned that the serialization could turn out to be a can of worms.

I'm more sympathetic to the notion of throwing an exception rather than serializing null. It seems we should be able to tell when we are about to do that? It's potentially incompatible but only for people who have been seeing these mysterious null values in their JSON and not cared. We could maybe have a GsonBuilder option or even system property for people like that.

[Marcono1234]

We could maybe have a GsonBuilder option or even system property for people like that.

That might not even be necessary, they can probably just register an ExclusionStrategy which behaves like the current built-in exclusion logic for local and anonymous classes.