2015-04-07 20:05 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
> Hi
>
> This topic is very interesting but I think we should just align by default
> on javabeans and allow a configuration (+api) for other usages which are
> widely spread over applications.
>
> So I propose:
>
> - default: getter/setter only, no field check at all,
>
I think it is more friendly to have public methods and fields (for example
if one has a immutable pojo with all fields public).
> support of addX for collections and maybe getter in write mode as in jaxb.
>
I am hesitating for addX not sure I like it...
What is getter in write mode?
> I like it cause it really exposes an API and not internals.
> - a shortcut in config api to use fields (either only or in cumulative
> mode) - this is too common to not be handled and the default in most ee API
> (JPA for instance)
> - add in API an abstraction for it for advanced mode and evolutions
> (Accessor, and AccessorFinder - I am not happy of the naming but was to
> share the idea). It would allow to add processor on the accessors to filter
> or remap them pretty easily. It makes trivial remapping, version and
> blacklist handling for instance.
> Le 7 avr. 2015 19:57, "Martin Vojtek" <voytoo_at_gmail.com> a écrit :
>
>> It would be great to hear opinions from others on this topic.
>>
>> Current JSON-B proposal is to by default ser/deser only fields where
>> field is present. Specifically, if there is field and set/get method,
>> set/get method is used. If there is not set/get method, field is used. If
>> there is no field, but get/set method, it is not used (JSON-B will not
>> consider this property). This behavior should be customizable. Maybe it is
>> too restrictive and if there is getter and no field, getter should be used.
>> What if there are methods not intended to be getters? What if there is
>> method isValue and getValue?
>>
>> For properties that are being renamed ... I can imagine use of
>> annotations.
>>
>> MartinV
>>
>> On Tue, Apr 7, 2015 at 4:27 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
>> wrote:
>>
>>> Oh, yes, in fact this is something I did on purpose for a couple of
>>> reasons. One of them is to allow people to ser types based on some "parent
>>> type". For example if a class implements several interfaces and we want to
>>> serialize using only one "aspect" of the instance.
>>> The other reasons are more opinionated :)
>>>
>>> So in JSONB how do you see things, would we ser only properties that
>>> have a field+get+set? I would prefer not or at least provide a config for
>>> it.
>>>
>>> However something that is a bit similar, from what I've seen, merging
>>> annotations from field/get/set is the good way to go. Initially I thought
>>> it would be better to decouple ser from deser aspect. But in the end I
>>> found that from an usage point of view, people expect that annotations that
>>> have been put on the field are being used also for get and set. The issue
>>> with this is how would one handle properties that are being renamed? I am
>>> quite interested in others opinion on this as I couldn't make my mind yet :)
>>>
>>> Thanks!
>>> Eugen
>>>
>>> 2015-04-07 16:00 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>>
>>>> The example I was thinking about is following:
>>>>
>>>> interface FunctionalInterface<T> {
>>>> public T getValue();
>>>> }
>>>>
>>>> Genson:
>>>>
>>>> public void test() {
>>>>
>>>> FunctionalInterface<String> myFunction = () -> {return "value1";};
>>>>
>>>> assertEquals("{\"value\":\"value1\"}",
>>>> genson.serialize(myFunction));
>>>>
>>>> }
>>>>
>>>> Proposed JSON-B:
>>>>
>>>> FunctionalInterface<String> myFunction = () -> {return "value1";};
>>>>
>>>> assertEquals("{}", jsonb.toJson(myFunction));
>>>>
>>>>
>>>> The difference is in handling getters when there is no field.
>>>>
>>>> MartinV
>>>>
>>>>
>>>>
>>>> On Mon, Apr 6, 2015 at 11:22 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> 2015-04-06 22:47 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> response inlined.
>>>>>>
>>>>>> Thanks,
>>>>>> Martin
>>>>>>
>>>>>> On Sun, Apr 5, 2015 at 5:57 PM, Oleg Tsal-Tsalko <
>>>>>> oleg.tsalko_at_gmail.com> wrote:
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> Will add example:
>>>>>>
>>>>>> List<java.util.Optional<String>> expected = Arrays.asList(Optional.empty(), Optional.ofNullable("first"), Optional.of("second"));
>>>>>>
>>>>>> String json = toJson(expected, DefaultMappingGenerics.class.getField("listOfOptionalStringField").getGenericType());
>>>>>> assertEquals("[null,\"first\",\"second\"]",json);
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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...
>>>>>>>
>>>>>>
>>>>>> Don't see reason why it is not valid scenario.
>>>>>>
>>>>>> Genson supports it (with different result in some cases as proposed
>>>>>> JSON-B) :)
>>>>>>
>>>>>
>>>>> Heh looks like you had an in depth look at it :) In what situation did
>>>>> it produce different or undexpected results?
>>>>>
>>>>> I added it because the effort to support it was not so important and
>>>>> this can be of some use. But this looks like a rare use case so I am not
>>>>> feeling strongly for or against it. I don't feel so concerned by the
>>>>> examples as IMO they are just examples and its OK if they don't cover all
>>>>> the API (after all it is not the spec).
>>>>>
>>>>> About supporting deser missing properties I 100% agree with the remark
>>>>> but think it should be expressed as a config option that would make things
>>>>> clear that impl. have to support this feature (and don't really care about
>>>>> the example).
>>>>>
>>>>> I wonder if providing those examples doesn't make things more
>>>>> confusing about what is the contract that impls should respect.
>>>>>
>>>>> Eugen
>>>>>
>>>>>
>>>>>> It would be helpful to hear some opinions from others on this topic.
>>>>>>
>>>>>>
>>>>>>> 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}]}
>>>>>>>
>>>>>>>
>>>>>> Will fix asap.
>>>>>>
>>>>>>
>>>>>>> Have a great Easter!
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Oleg
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>