On Tue, Sep 1, 2009 at 9:44 AM, Paul Sandoz<Paul.Sandoz_at_sun.com> wrote:
...
> I assume it's true of any parameterized type, yes? And is true whether one
> uses JSON or application/xml?
>
> Yes.
> I will implement support for a type T, but types like T[], Collection<T> and
> Map<T, Collection<V>> are harder to resolve because it is difficulty
> creating the concrete parameterized type definitions. If anybody knows of
> any mechanism to help aid this i am all ears!
I may be missing something, but I suspect it is possible to resolve
other types if you can resolve T itself, since it's just a recursive
process. You do need to carry along context to resolve T, but
otherwise shouldn't it just be recursive resolution (not that that's
trivial -- Java type class hierarchy is weird -- just possible).
I spent quite some time adding better support for generics in Jackson,
and found ways to support many of commonly used constructs. But type
erasure does became problem all too often.
For what it's worth, some problems with generic collections (and Maps)
are due to XML information model.
If so, using native JSON provider (like Jackson's JAX-RS provider) can
help. But that's just a subset of all problems -- in general, one has
to ensure that type erasure does not get rid of all type information.
And usually what that means is that one must use concrete sub-classes
of generic types: casts and inline declarations are things that are
not visible during runtime.
-+ Tatu +-