I just checked in an update to JSONSerializer that improves support for
deserializing typed lists and maps. The following approaches are now supported:
- Parameterized property of Java bean class; e.g. public ArrayList<Foo>
getFooList() {...}
- TypeLiteral
- Subclass of concrete generic sequence or dictionary; e.g. public class
FooList extends ArrayList<Foo> {...}
- Direct implementation or subclass of Sequence<T> or Dictionary<String, V>;
e.g. public class FooSequence implements Sequence<Foo> {...}
From a user standpoint, there isn't any real distinction between the latter
two, but the implementation is slightly different - the first case gets the
item/value type from a generic base class, whereas the second gets it from the
Sequence interface itself.
You can see examples of each approach in org.apache.pivot.json.test.BindTest.
Let me know if you have any questions.
G
On Nov 24, 2010, at 9:58 PM, Greg Brown wrote:
> Turns out this doesn't work, presumably due to type erasure. I think I'll
> need to walk up the type hierarchy to find the parameterized Sequence type
> and get the actual type arguments from that.
>
> On Nov 24, 2010, at 8:17 PM, Greg Brown wrote:
>
>> I see the problem now. When you create a subclass of a generic, it is no
>> longer considered a parameterized type, so the code that obtains the raw
>> type and type parameters from the generic isn't executed. Instead, the
>> actual class type is instantiated, and the item type is set to Object.class.
>> This is wrong - the item type should be obtained by using reflection to get
>> the return value of get(int). The same applies to Dictionary types
>> (get(String) should be used to get the value type).
>>
>> I'll try to fix this later tonight or tomorrow.
>>
>> On Nov 24, 2010, at 7:26 PM, Bill van Melle wrote:
>>
>>> Good, the TypeLiteral works okay now. Any idea why the other way doesn't
>>> work (using a class that extends ArrayList<Foo>)? Perhaps the element type
>>> is hard to find when it's in a parent class.
>>>
>>>
>>
>
