Hi,
let me express my few cents here.
At the beginning I didn't like Type as is might me cumbersome to build it
and could bring a lot of boilerplate code. I preferred plain Class,
unfortunately as you all know generic types information in such case is
deleted in runtime. This way I'm leaning towards support of Type, even if
having in API a class coming from java.lang.reflect seems quite odd :)
Anything that is not backed up by JLS is at least suspicious (even if it
works very well) and I would definitely not put TypeToken in the API. In
the worst case it might be a part of the reference implementation, but as
Martin explained before it works as a side effect (?) - do we even know if
TypeToken (trick) works also on other JVMs than OpenJVM and Oracle ones?
---
In a perfect world we don't have constraints or limitations. In reality we
have to stop at some point and consider the most useful features and drop
the extreme corner cases (80/20 rule you probably all know) if they are too
costly or can influence "badly" the API. It's up to us to decide which ones
are the most common.
As a developer (JSONB user) I would expect to have at least the same level
of generic support than JAXB. The reason is very simple - many users will
want to reuse their existing JAXB classes to serialize/deserialize JSON
(they already do it but using non-standard solutions). I haven't seen much
complaining about generic type support in JAXB, so it should be also enough
for new or pure JSON users.
Some of you will probably shout that we should also (if not in the first
place) support existing JSON binding libraries users, but I'm not sure
which is more important. For me it would be JAXB users - but I don't have
any scientific data to back up my position - it's simply my gut feelings.
Cheers,
Przemyslaw
On Fri, Mar 13, 2015 at 8:51 PM, Romain MB <rmannibucau_at_tomitribe.com>
wrote:
>
> Le 13 mars 2015 19:50, "Inderjeet Singh" <inder_at_alumni.stanford.edu> a
> écrit :
>
> >
> >
> >
> > On Fri, Mar 13, 2015 at 10:57 AM, Romain MB <rmannibucau_at_tomitribe.com>
> wrote:
> >>
> >>
> >> > Map may have the same issue but in practice I don't see APIs using
> Map as
> >> > the return type. Instead people use a regular class. OTOH, Lists are
> common
> >> > because often REST APIs return collections of resources.
> >> >
> >> >
> >>
> >> Well saw it regularly on cloud solutions and devoxx API at least.
> >
> >
> > If I was a client developer for those APIs, I would use a Class instead
> of a Map to convert the API JSON response.
> > Unless the API is too crazy (where the field names keep changing at
> random, or are just too numerous), this remains a viable option that we
> will tell the developers to use.
> >
> >
>
> Well that is in a perfect world. Not doable in previous samples. Think to
> a schedule indexed by conferences hours or name or environment keys...
>