I have the same doubt. Are there any specific reasons why anonymous or local 
classes should be excluded?

I tried to disable the DEFAULT_ANON_LOCAL_CLASS_EXCLUSION_STRATEGY. It does not 
seem producing any problems

And inner class will trigger problems using a type adapter is specified for the 
class since it generated an implicit reference to the outer class/instance 
which causes a circular reference. I do not recall the reason as to why we skip 
anonymous classes.

I will discuss this with Inder, but I do think that this is a valid feature 
that we should support.

Issue 196 has been merged into this issue.

Issue 346 has been merged into this issue.

I respectfully disagree.

I'm doing something like this.

I have an interface, TFlat. I registered a custom serializer for that interface.

I have:

class O {
  TFlat p = new TFlat(){ int field1 = 3; int field2 = 4; }
  ...
}

And I'm trying to serialize an instance of O.

May be the exclusion strategy should pass out anonymous/local classes that 
would have be serialized in a custom way?

Thanks,
  Pawel.

Pawel, that's interesting I'll take a look. What do you think should happen 
when this is deserialized?

Jesse,

I don't think this is particularly useful for deserializing.
If we were to stretch this, deserialization can see that the field is 
initialized, and if the incoming JSON fragment is an object, map the properties 
of the fragment to the fields of the object. IMO, right now, GSon always 
attempts to instantiate classes that are declared for each field (or use a 
custom deserializer to do so).

custom deserialization can create its own anonymous class that will implement 
TFlat. It would need to know the field location (somehow indicate where the 
field will go after deserialization), though, which is, to my knowledge, is not 
something GSon supports either. But I'm still on 1.7, haven't checked out all 
the 2.x goodies.

[deleted comment]

Interestingly enough, you can create instances of anonymous objects.
However, such instances will not be "attached" to the outer class, yet they are 
legal. Attempting to reference parent class will simply return null. Obvious 
problem is, of course, that there is no way to declare a field of anonymous 
class.

Here is the Groovy fragment I ran to test this:


interface T {
}
class P {
  int out = 13;
  T z = new T() {
    int k;
    {
        System.out.println("Anonymous <init>...");
        P parent = P.this;
        if (parent == null) { System.out.println("No Parent!"); }
        else { System.out.println(parent.out) }; 
    }
  };
}
P p = new P();
Class<T> cc = p.z.getClass();
System.out.println(cc.getName());
T another = cc.newInstance();
---
output:
Anonymous <init>...
13
P$1
Anonymous <init>...
No Parent!
Result: P$1@1567ee3

We still use gson-1.3 due to this issue...

Today I found http://code.google.com/p/google-gson/issues/detail?id=96 in our 
logs.
The bug fixed in 1.4++, but we can't move to fresh version of gson since we 
have a lot of inner/local classes to serialize.

Same here. Even though I love GSON simplicity and extensibility, but inability 
to serialize anonymous classes simply kills the practical usability of this 
great library!

The use case I'm talking about is very simple and widely used. Image you have 
class Car:
public class Car {
   String name;
   String color;
}

Let's create 2 instances using different code-style:

   Car car1 = new Car();
   car1.name = "BMW";
   car1.color = "Red";

   Car car2 = new Car() {{
      name = "Nissan";
      color = "Gold";
   }}

car2 object has the same number of fields and from logical perspective it is of 
the same type than car1. The anonymous Car subclass created for the car2 
instance can be safely ignored in this case as it doesn't add anything to the 
car2 that car1 wouldn't have. So why would Gson refuse processing car2?

Don't use double brace initialization. It prevents serialization and Gson is 
designed for symmetric serialization and serialization.

jackson can do this:
        ObjectMapper mapper = new ObjectMapper();
        mapper.setVisibility(PropertyAccessor.FIELD, Visibility.ANY);
        String result=mapper.writeValueAsString(x);
why gson not?