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