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
>>>>>
>>>>
>>>>
>>>
>>
>