Just to add that I saw almost all jaxb users - inluding me - complaining
about the need of wrapping lists and maps. This is clearly something to not
force and why Type is surely a good start.
There are a lot of json api in real life and mapping them 1-1 should be
supporting IMO to ensure the success of jsonb. This includes direct List
and Map.
Le 16 mars 2015 08:58, "Przemyslaw Bielicki" <pbielicki_at_gmail.com> a écrit
:
> 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...
>>
>
>