jsr367-experts@jsonb-spec.java.net

[jsr367-experts] Re: [jsonb-spec users] Re: Re: Fwd: Re: Re: Re: Re: [30-GenericTypeSupport] Proposal

From: Eugen Cepoi <cepoi.eugen_at_gmail.com>
Date: Sat, 11 Apr 2015 21:11:34 +0200

2015-04-11 21:01 GMT+02:00 Romain Manni-Bucau <rmannibucau_at_tomitribe.com>:

> Javabeans has @ConstructorProperties which fits the need IMO.
>
> Immutability is another topic we should be compliant to but not force IMO
> - dont want to go to far in this thread on it since it is close to
> religion since technically there is no strong reason to enforce it.
>
Most of the stuff we discuss here is close to a religion :p You are right,
there is no need to be too strongly positioned as all this depends on use
cases and opinions.

>
> Le 11 avr. 2015 19:54, "Inderjeet Singh" <inder_at_alumni.stanford.edu> a
> écrit :
> >
> > Agree with "public final fields" being an acceptable practice.
> >
> > IMO, Encapsulation is about programmatic access to objects, not about
> its serialized form.
> > What goes on the wire is data, which is best represented by fields. I
> agree that fields are an internal representation and may not accurately
> represent what you want on wire.
>
I think we overall agree :)

> > In practice though, it rarely is a problem. For those rare cases, Custom
> Type adapters fit the bill.
> >
> > In Genson, how do you invoke the constructor while passing arguments
> since the parameter names are not retained at runtime. How do you figure
> out which JSON field maps to which parameter?
>

For code compiled with debug symbols you have the parameter names in the
byte code (this is true for most of the code by default). I am using this
to extract the parameter names (and reflection to get the types), once it
is done the mapping is pretty straightforward.
I don't remember if it is in the reflection API but java 8 provides now
also a way to get the parameter names (using a similar technique).

Cheers,
Eugen

> >
> > Inder
> >
> >
> >
> >
> > On Sat, Apr 11, 2015 at 10:23 AM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
> wrote:
> >>
> >>
> >>
> >> 2015-04-11 18:28 GMT+02:00 Inderjeet Singh <inder_at_alumni.stanford.edu>:
> >>>
> >>> I stand by my assertions on good coding practices and there is plenty
> of literature to support them. Briefly,
> >>> 1. Public fields break encapsulation so should be avoided.
> >>> 2. Immutability enhances thread-safety, and avoid unintended
> side-effects (you can safely return internal objects in methods without
> worrying about someone modifying them).
> >>>
> >>> However, I agree that there are no absolutes and mutability has its
> place. That is why these are good practices, not requirements.
> >>>
> >>> My problem is when a technology makes it hard or impossible for me to
> follow these practices. For example, JPA forces me to make my fields
> mutable. I don't like that a single bit.
> >>> On the contrary, Gson encourages you to define fields as private
> final, thus enabling encapsulation and immutability.
> >>
> >>
> >> Serializing private fields is breaking this encapsulation.
> >> I think having public final fields is fine and don't feel it as a bad
> practice, or at least it depends on the use case. Anyway until people can
> configure their Jsonb instance to support whatever they like, I am fine
> with it.
> >>
> >> About immutability, the best solution IMO is to support constructors
> with arguments (not generating ctrs via Unsafe or passing null/default
> values or expecting people to write custom code). That's how I am trying to
> encourage immutability in Genson - for now it works pretty well.
> >>
> >> Eugen
> >>
> >>>
> >>> I consider that to be a better design. JSR-367 should follow similar
> principles.
> >>>
> >>>
> >>> Inder
> >>>
> >>>
> >>>
> >>> On Sat, Apr 11, 2015 at 7:55 AM, Romain Manni-Bucau <
> rmannibucau_at_tomitribe.com> wrote:
> >>>>
> >>>>
> >>>> Le 11 avr. 2015 16:24, "Inderjeet Singh" <inder_at_alumni.stanford.edu>
> a écrit :
> >>>> >
> >>>> > The design should encourage great coding practices. Supporting
> public fields will do the opposite.
> >>>> >
> >>>>
> >>>> Yes and no. It makes sense in some cases. I'd let it up to users and
> their programming model.
> >>>>
> >>>> > Another great coding practice is making classes immutable. Which
> means no setters either.
> >>>> >
> >>>>
> >>>> Why? This is wrong in the absolute but right in some context like
> message passing pattern usage. Someone could say you immutable is bad
> cause of memory profile it mandates.
> >>>>
> >>>> Here I would just align on java ie supporting accessors AND
> constructor usage (being aligned on javabeans let user do what he wants
> without forcing one of both patterns)
> >>>>
> >>>> > Inder
> >>>> >
> >>>> >
> >>>> >
> >>>> > On Sat, Apr 11, 2015 at 4:16 AM, Martin Vojtek <voytoo_at_gmail.com>
> wrote:
> >>>> >>
> >>>> >> 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
> >>>> >>>>>>>>>>
> >>>> >>>>>>>>>>
> >>>> >>>>>>>>>
> >>>> >>>>>>>>
> >>>> >>>>>>>
> >>>> >>>>>>
> >>>> >>>>
> >>>> >>
> >>>> >
> >>>
> >>>
> >>
> >
>