Forgot to mention something super important: what will be the first usage
at EE level? Retirning a JPA entity in a JAX-RS service IMO so being super
close to JPA can be nice - wonder about lazy relationships btw...
Le 11 avr. 2015 21:12, "Eugen Cepoi" <cepoi.eugen_at_gmail.com> a écrit :
>
>
> 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
>> >>>> >>>>>>>>>>
>> >>>> >>>>>>>>>>
>> >>>> >>>>>>>>>
>> >>>> >>>>>>>>
>> >>>> >>>>>>>
>> >>>> >>>>>>
>> >>>> >>>>
>> >>>> >>
>> >>>> >
>> >>>
>> >>>
>> >>
>> >
>>
>
>