Hi guys,
Feedback on generic mapping serialization examples:
1) Why there are no examples of actual usage of proposed
Jsonb#toJson(Object, Type) method?
I assume these examples should justify usage of this advanced method in
those special/tricky cases where Jsonb#toJson(Object) method is not enough.
2) Probably it was missed by me but are we going to support serialization
of anonymous interfaces/classes implementations at all?
As an example:
myFunction = new FunctionalInterface<String>() {
private String value = "initValue";
@Override public String getValue() {
return value;
}
public void setValue(String value) {
this.value = value;
}
};
assertEquals("{\"value\":\"initValue\"}", jsonb.toJson(myFunction));
It doesn't look like valid scenarios to support.
AFAIK, Gson lib doesn't support this...
3) Expected result in bounded example doesn't look right:
assertEquals("{\"boundedSet\":[3],\"superList\":[{\"radius\":2.5}]}",
jsonb.toJson(boundedGenericClass));
I believe it should be:
{"boundedSet":[3],"superList":[{"area":0.0,"radius":2.5}]}
Have a great Easter!
Thank you,
Oleg
2015-03-16 10:48 GMT+02:00 Przemyslaw Bielicki <pbielicki_at_gmail.com>:
> +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...
>>>>
>>>
>>>
>