+1 for supporting Lists and Maps - I personally use this a lot
On Mon, Mar 16, 2015 at 9:34 AM, Romain Manni-Bucau <
rmannibucau_at_tomitribe.com> wrote:
> 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...
>>>
>>
>>