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