Alright, I don't see big enthusiasm for the idea of private fields included
in default mapping :)
So, the second proposal is as follows:
- support public fields
- support get/set
If there is get/set, use it.
If there is just public field, use it.
If there is just get/set and no field, use get/set.
Other options should be configurable.
MartinV
On Sat, Apr 11, 2015 at 11:17 AM, Romain MB <rmannibucau_at_tomitribe.com>
wrote:
> While field visibility can be customized by method it works - ie private
> getter hides fields during ser - but does it make sense to support fields
> not accessible by code at all by default? I am not convinced. Means design
> is broken even if I understand it is technical only objects. Think staying
> aligned on java is not that bad.
> Le 10 avr. 2015 22:43, "Inderjeet Singh" <inder_at_alumni.stanford.edu> a
> écrit :
>
>> In Gson, we agonized over this issue periodically.
>>
>> In the end, I think our current approach works. Just support fields
>> (public or private), and ignore methods. The developers should use custom
>> type adapters for anything more complicated.
>>
>> Inder
>>
>>
>>
>>
>> On Fri, Apr 10, 2015 at 12:33 PM, Romain Manni-Bucau <
>> rmannibucau_at_tomitribe.com> wrote:
>>
>>> Well issue supporting private fields by default is you dont expose
>>> correct payload (API for REST endpoint!!) if you need any internal
>>> variable which is super risky compared to have to activate field visibility
>>> manually.
>>>
>>> That said I am happy while it is customizable.
>>> Le 10 avr. 2015 20:38, "Eugen Cepoi" <cepoi.eugen_at_gmail.com> a écrit :
>>>
>>>>
>>>>
>>>> 2015-04-10 20:11 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>>>
>>>>> Interesting point of view. I was thinking mainly about deser scenario
>>>>> and no mixin.
>>>>>
>>>>> I still see public fields more like a not so good design decision
>>>>> (instead of public contract).
>>>>>
>>>>
>>>> Depends, public final fields look good to me (only if final). Esp. when
>>>> it is supposed to exclusively hold "public" data.
>>>> But I guess it is more of a religion if you are alergic to get/set or
>>>> not - as you can guess I am :)
>>>>
>>>>
>>>>>
>>>>> I think there are two regular cases:
>>>>>
>>>>> 1. class with all fields private with get/set methods
>>>>>
>>>>> 2. class with just non public fields
>>>>>
>>>>> Other not so good cases (by design) :)
>>>>>
>>>>> - class with all fields public (no get/set)
>>>>>
>>>>> - class with mix of fields and get/set methods.
>>>>>
>>>>> Anyway, I still think it is better to support all these cases. If user
>>>>> doesn't want some property to be serialized into json, he could put
>>>>> annotation or transient keyword on the given field or set/get method.
>>>>>
>>>>>
>>>> Yeah sure but it could be the other way too, only public + annotate
>>>> what else you want to include or configure your instance of Jsonb to do so.
>>>> Anyway, if there is a option to configure visibility in Jsonb (without
>>>> annotations) I am fine with it.
>>>>
>>>> Eugen
>>>>
>>>>
>>>>> What do others think about support of private fields by default?
>>>>>
>>>>
>>>>> MartinV
>>>>>
>>>>>
>>>>> On Fri, Apr 10, 2015 at 7:11 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Just some insights about mixing by default public and private...
>>>>>>
>>>>>> 2015-04-08 20:31 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>>>>>
>>>>>>> I vote for the following (default mapping):
>>>>>>>
>>>>>>> - support private fields (private fields are good habit in Java)
>>>>>>>
>>>>>>
>>>>>> Doing ser/de by using private fields when at the same time one uses
>>>>>> public contract can be source of problems.
>>>>>>
>>>>>> As a user
>>>>>> - I want to ser/de all the private fields when I am doing some RPC
>>>>>> because on the other side I will use this technical low level
>>>>>> representation to provide the same contract other the private data (in this
>>>>>> situation I just don't want the lib to look at methods, but take all the
>>>>>> private fields except transient/static).
>>>>>>
>>>>>> - I want to ser/de using public methods and fields to expose a kind
>>>>>> of API/public data. In this situation I don't want the lib to pick my
>>>>>> private fields because they are the way I internally represent stuff, the
>>>>>> consumer doesn't have to know about that.
>>>>>>
>>>>>> That's also the logic I followed when making Genson. I think exposing
>>>>>> both by default is wrong...(but one can still use the annotations from a
>>>>>> field and apply them to a method, just not ser/de protected/private stuff
>>>>>> by default)
>>>>>>
>>>>>>
>>>>>>
>>>>>>> - support get/set
>>>>>>>
>>>>>>> If there is get/set, use it.
>>>>>>> If there is just field, use it.
>>>>>>> If there is just get/set and no field, use get/set.
>>>>>>>
>>>>>>> Other options should be configurable.
>>>>>>>
>>>>>>> MartinV
>>>>>>>
>>>>>>> On Wed, Apr 8, 2015 at 11:25 AM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015-04-08 10:17 GMT+02:00 Hendrik Dev <hendrikdev22_at_gmail.com>:
>>>>>>>>
>>>>>>>>> (sorry, wrong list)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>> From: Hendrik Dev <hendrikdev22_at_gmail.com>
>>>>>>>>> Date: Wed, Apr 8, 2015 at 10:16 AM
>>>>>>>>> Subject: Re: [jsonb-spec users] Re: [jsr367-experts] Re: Re: Re:
>>>>>>>>> [30-GenericTypeSupport] Proposal
>>>>>>>>> To: users_at_jsonb-spec.java.net
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I would say: Support all variants (fields and/or (getters/setters))
>>>>>>>>> including private fields and by default use only getter/setters
>>>>>>>>> (and
>>>>>>>>> no fields). Thats what the most users would expect AFAIK.
>>>>>>>>>
>>>>>>>>
>>>>>>>> In genson I include public fields by default, it sounds natural to
>>>>>>>> me as the public methods and fields define the "exposed" contract about the
>>>>>>>> data. Then users can customize it as they want.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Dont know if just getters or just setters is really useful, IMHO it
>>>>>>>>> complicates the thing without adding real value (can be done with
>>>>>>>>> @Ignore if really necessary)
>>>>>>>>>
>>>>>>>>
>>>>>>>> Agreed.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> We do this in Johnzon via AccessMode
>>>>>>>>> (
>>>>>>>>> https://github.com/apache/incubator-johnzon/blob/master/johnzon-mapper/src/main/java/org/apache/johnzon/mapper/access/AccessMode.java
>>>>>>>>> )
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Hendrik
>>>>>>>>>
>>>>>>>>> On Wed, Apr 8, 2015 at 9:33 AM, Oleg Tsal-Tsalko <
>>>>>>>>> oleg.tsalko_at_gmail.com> wrote:
>>>>>>>>> > Hi guys,
>>>>>>>>> >
>>>>>>>>> > My vote (if it counts) is to definitely support by default all
>>>>>>>>> variants
>>>>>>>>> > (e.g. fields/getters/setters) in all combinations (e.g.
>>>>>>>>> getters+setters or
>>>>>>>>> > just getters or just setters even if it silly usage from user
>>>>>>>>> perspective) +
>>>>>>>>> > with private access.
>>>>>>>>> > The only thing we need to decide on relative priorities to
>>>>>>>>> resolve ties if
>>>>>>>>> > any.
>>>>>>>>> >
>>>>>>>>> > Thank you,
>>>>>>>>> > Oleg
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > 2015-04-07 22:16 GMT+03:00 Romain MB <rmannibucau_at_tomitribe.com
>>>>>>>>> >:
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> Le 7 avr. 2015 21:07, "Eugen Cepoi" <cepoi.eugen_at_gmail.com> a
>>>>>>>>> écrit :
>>>>>>>>> >> >
>>>>>>>>> >> >
>>>>>>>>> >> >
>>>>>>>>> >> > 2015-04-07 20:48 GMT+02:00 Romain MB <
>>>>>>>>> rmannibucau_at_tomitribe.com>:
>>>>>>>>> >> >>
>>>>>>>>> >> >>
>>>>>>>>> >> >> Le 7 avr. 2015 20:27, "Eugen Cepoi" <cepoi.eugen_at_gmail.com>
>>>>>>>>> a écrit :
>>>>>>>>> >> >> >
>>>>>>>>> >> >> >
>>>>>>>>> >> >> >
>>>>>>>>> >> >> > 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).
>>>>>>>>> >> >> >
>>>>>>>>> >> >>
>>>>>>>>> >> >> Fair enough
>>>>>>>>> >> >>
>>>>>>>>> >> >> >>
>>>>>>>>> >> >> >> 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?
>>>>>>>>> >> >> >
>>>>>>>>> >> >>
>>>>>>>>> >> >> getMyCollection().add(xx) instead of just using
>>>>>>>>> setMyCollection(col)
>>>>>>>>> >> >
>>>>>>>>> >> >
>>>>>>>>> >> > Ok I understand better what you mean. I can see only 2 use
>>>>>>>>> cases for
>>>>>>>>> >> > this: when adding stuff to the list the pojo is doing
>>>>>>>>> something (increment a
>>>>>>>>> >> > counter for example) or updating an existing instance (kind
>>>>>>>>> of merge).
>>>>>>>>> >>
>>>>>>>>> >> Well jaxb does it cause setColl makes the API not that natural
>>>>>>>>> I think.
>>>>>>>>> >>
>>>>>>>>> >> > I don't think we provide any merge solution now so point 2 is
>>>>>>>>> excluded
>>>>>>>>> >> > and 1 is still valid even if I don't like it :)
>>>>>>>>> >> >
>>>>>>>>> >>
>>>>>>>>> >> +0, being aligned on other specs would be nice as well. JPA
>>>>>>>>> started
>>>>>>>>> >> without merges then added it to make it smooth for users. When
>>>>>>>>> we dont know
>>>>>>>>> >> or there is a conflict it is easy to fail - like jaxb.
>>>>>>>>> >>
>>>>>>>>> >> >
>>>>>>>>> >> > Eugen
>>>>>>>>> >> >>
>>>>>>>>> >> >> >>
>>>>>>>>> >> >> >> 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
>>>>>>>>> >> >> >>>>>>>>
>>>>>>>>> >> >> >>>>>>>
>>>>>>>>> >> >> >>>>>>
>>>>>>>>> >> >> >>>>>
>>>>>>>>> >> >> >>>>
>>>>>>>>> >> >> >>>
>>>>>>>>> >> >> >
>>>>>>>>> >> >
>>>>>>>>> >> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Hendrik Saly (salyh, hendrikdev22)
>>>>>>>>> @hendrikdev22
>>>>>>>>> PGP: 0x22D7F6EC
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Hendrik Saly (salyh, hendrikdev22)
>>>>>>>>> @hendrikdev22
>>>>>>>>> PGP: 0x22D7F6EC
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>