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