I vote for the following (default mapping):
- support private fields (private fields are good habit in Java)
- 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
>>
>
>