Yes, if there is get/set accessor (in terms of JavaBeans), use this get/set
accessor.
On Sat, Apr 11, 2015 at 1:21 PM, Romain MB <rmannibucau_at_tomitribe.com>
wrote:
>
> Le 11 avr. 2015 13:16, "Martin Vojtek" <voytoo_at_gmail.com> a écrit :
> >
> > 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.
>
> Here "it" means accessors right?
>
> > 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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> >
>