Check parent class for ParameterizedTypeHandlerMap

[GoogleCodeExporter]

TypeConverter need exact class

registerTypeAdapter(Foo.class, new FooTypeAdapter()) doesn't works for 
subclass of Foo

it must be 

registerTypeAdapter(ChildOfFoo.class, new 
FooTypeAdapter()).registerTypeAdapter(Child2OfFoo.class, new 
FooTypeAdapter()).registerTypeAdapter(Child3OfFoo.class, new 
FooTypeAdapter())....

this patch can solve this problem.

Original issue reported on code.google.com by zhouyanm...@gmail.com on 10 Oct 2009 at 6:57

Attachments:

• patch.txt

[GoogleCodeExporter]

We were aware of this issue when we were designing the ParameterizedHandlerMap. 
The reason that it doesnt 
support subclasses is that SubClasses usually contain extra fields, and 
applying a base-class type adapter will 
result in unintended consequences (since the base class handler may not be 
designed to work with the extra 
fields of subclasses). 

In a future release of Gson, we are thinking of providing a way to address 
common use-cases around this. For 
example, we could provide an annotation that is used to determine the type of 
the object to deserialize into. Or a 
variant of your suggestion.

Original comment by inder123 on 10 Oct 2009 at 6:11

[GoogleCodeExporter]

I've been frustrated by this surprising limitation myself, having spent a good 
deal of time developing a generic EObject (as in Eclipse EMF) type adapter, 
which uses Ecore metadata to determine which features to serialize and how.

A related use case relates to serialization of interfaces. The current adapter 
lookup code uses the object class as the key; I would like to be able to 
register type adapters by interface (such as EObject).

I'd have thought it would have made sense to:
1. provide a GsonBuilder setting to enable serialization-via-superclass
and/or
2. add a JsonSerializer.isAdapterForType(Type) : boolean method so that a 
serializer which matches on superclass/(super)interface can indicate whether it 
wants to handle a given subclass/subinterface.

Without this flexibility it is hard to define a generalized reusable serializer 
- as things currently stand you must explicitly register such a serializer for 
every conceivable class it may be required to handle. This is tedious and 
inefficient at best and impossible at worst, since you may not know in advance 
what the subclasses are (in my own scenario, unknown generated Ecore packages 
extending known types can be contributed by 3rd party extensions).

I would greatly welcome improvements in this area :-)

Thanks,

Adrian Price
Senior Architect
TIBCO Software Inc.

Original comment by adrianp....@gtempaccount.com on 1 Oct 2010 at 12:54

[GoogleCodeExporter]

This is related to issue 242, where enums frequently have anonymous subclasses 
that aren't easily registered in the type adapter map.

Original comment by limpbizkit on 3 Nov 2010 at 4:02

[GoogleCodeExporter]

I think we might want to reconsider this behavior in 1.7.

The attached patch demonstrates how the current behavior is quite surprising. 
The core problem is that sometimes we use the type adapter and sometimes we 
don't. We use it if it's assigned to the static type (such as the field type); 
we don't use it if we don't have static type information, or if we don't have 
sufficient static type information and we use runtime type information.

I particularly don't like how GSON does different things depending on how much 
type information it has.

Original comment by limpbizkit on 3 Nov 2010 at 4:18

Attachments:

• Runtime_TypeAdapters.patch

[GoogleCodeExporter]

Original comment by limpbizkit on 3 Nov 2010 at 4:18

• Added labels: Milestone-Release1.7

[GoogleCodeExporter]

Obsolete by GsonBuilder.registerTypeHierarchyAdapter().

Original comment by limpbizkit on 29 Dec 2011 at 7:20

• Changed state: WontFix

[GoogleCodeExporter]

Issue 125 has been merged into this issue.

Original comment by limpbizkit on 30 Dec 2011 at 6:28