On Sep 1, 2009, at 7:38 PM, Tatu Saloranta wrote:
> 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.
>
Yes, Jersey can support the resolving of T for a request entity by
traversing the class hierarchy and that is the solution i will use to
solve the resolving of T in all contexts with the "abstract model" and
will be able to report errors if T cannot be resolved.
But say we have:
public class X<T> {
@GET
public Collection<T> get() { ... }
}
public class Y extends X<MyJAXBBean> { ... }
or:
public class X<T> {
@GET
public T get() { ... }
}
public class Y<V> extends X<Collection<V>> { ... }
public class Z extends X<MyJAXBBean> { ... }
Then there is no way to directly resolve the parameterized type
Collection<T>, or Collection<V>, to Collection< MyJAXBBean> as the
latter type does not exist at runtime using reflection, and would have
to be created, and AFAIK the only way to create it would be to
actually define a class, for example:
public class _Collection_MyJAXBBean_ {
public Collection<MyJAXBBean> _x;
}
which means using some ASM. Essentially we are attempting to do what
the compiler does, in part, to perform static typing.
> 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.
Yes.
> 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.
>
What we need is a little ASM-based reflection-based library for
generics.
Paul.
> 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 +-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>