2015-04-07 19:55 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
> 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).
>
So by default it would also pick private fields?? In genson I choosed to
use by default only public/package methods and fields (with preference to
methods over fields). And allow then people to use one of the other and
customize visibility.
What about having get but not set (property being serialized but not
deserialized)?
Also I like using and allow people to use immutable objects without setters
and a ctr that takes all the arguments. I think the spec should let this
situation be possible (ex: not force get AND set).
> 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?
>
Thats a direct use for annotations or other exclusion strategy.
> What if there is method isValue and getValue?
>
We can throw an exception if there is ambiguity.
>
> For properties that are being renamed ... I can imagine use of annotations.
>
Sure annotations, but what I meant was: suppose you annotate field person
with @JsonIgnore and have getPerson annotated with
@JsonProperty("personFoo"), who should win?
>
> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>