Hi guys,
More feedback on default mapping:
1) We have following examples for JAXP structures mapping:
JsonStructure jsonStructure = jsonb.fromJson("{\"name\":\"unknown
object\"}", JsonStructure.class);
JsonObject jsonStructure = jsonb.fromJson("{\"name\":\"unknown object\"}",
JsonObject.class);
Does it makes sense to have following example:
JsonObject jsonStructure = (JsonObject)jsonb.fromJson("{\"name\":\"unknown
object\"}", JsonStructure.class);
just to emphasize that in runtime correct JsonStructutre instantiated?
Or it should be part of TCK rather then another example?
2) I didn't find examples for deserializing JSON with missing fields into
POJO which should result in null values I expect such as:
POJO pojo = jsonb.fromJson("{\"id\":1}", POJO.class);
assertEquals(1, pojo.id);
assertNull(pojo.name);
3) I didn't find example that shows is it allowed to use POJOs with private
fields without getters/setters?
4) Agree on restricting usage of static/final/transient fields and
private/overloaded constructors for POJOs used for ser/deser JSON data,
however disagree with not supporting deserialization of unknown fields.
Why not ignore all not mapped content of JSON doc during deserialization
rather then dictate strict one-to-one correspondence of JSON doc to POJO?
It will give user much more flexibility where he/she wants to map only part
of JSON doc he/she interested in.
5) [TYPO]: Function DefaultMapping#toJson_Anonymous_Class. Look like
instead of:
assertEquals("{\"id\":1,\"name\":\"pojoName\"}", new POJO() {...})
it should be
assertEquals("{\"id\":1,\"name\":\"pojoName\"}", jsonb.toJson(new POJO()
{...}))
6) [TYPO]: DefaultMapping line 834:
java.net.URI uri = new java.net.URI("mailto:users_at_jsonb-spec.java.net");
assertEquals("\"
https://www.jcp.org/en/jsr/detail?id=367#3\"",
jsonb.toJson(uri));
7) [TYPO]: DefaultMapping line 1034. Should be:
assertEquals("{\"optionalField\":\"value\"}", jsonb.toJson(optionalClass));
instead of
assertEquals("{\"optionalField\":\"value\"}", optionalClass);
Have a great Easter!
Thank you,
Oleg
2015-03-17 13:12 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
> +1 marshalling order is important
>
> About set of fields we have several cases:
> - using fields: we don't care much IMO
> - using methods: we have to align on java to not get surprises (if a
> setter uses another field/parent field)
> - using constructor: all is done smoothly
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-03-17 11:21 GMT+01:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
> > Hum, I don't know if it is worth to make deser order customizable. The
> only
> > use case I see where someone would want parent fields to be set first is
> > when he does some ugly init. logic in setters and the order matters. And
> > this use case sounds as bad code. Also this is too technical and low
> level
> > IMO to let the user configure anything. I'd say, let him configure the
> order
> > props are being ser. and thats all.
> >
> > 2015-03-17 11:11 GMT+01:00 Martin Vojtek <voytoo_at_gmail.com>:
> >>
> >> Hi Eugen, agree with performance issue. Let's set it in order.
> >>
> >> It should be customizable to allow other options.
> >>
> >> On Tue, Mar 17, 2015 at 10:58 AM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
> >> wrote:
> >>>
> >>> OK for 1 and 2, but I disagree with 3. It is inefficient, during deser.
> >>> lets "set" them in the order they appear in the stream.
> >>>
> >>> 2015-03-17 10:08 GMT+01:00 Martin Vojtek <voytoo_at_gmail.com>:
> >>>>
> >>>> I suggest the following default for inheritance, order of fields (for
> >>>> default mapping):
> >>>>
> >>>> 1. Fields MUST be marshalled(serialized) in lexicographical order.
> >>>> 2. Fields of super class MUST be marshalled(serialized) before fields
> of
> >>>> child class.
> >>>> 3. When unmarshalling, fields of super class MUST be set before fields
> >>>> of child class.
> >>>>
> >>>>
> >>>> ad examples: I will add examples for suggested cases. In general, feel
> >>>> free to
> >>>> send me diff file or create some github fork to propose
> changes/examples
> >>>> and I will incorporate it (if you don't have commit rights).
> >>>>
> >>>>
> >>>> MartinV
> >>>>
> >>>> On Mon, Mar 16, 2015 at 2:03 PM, Przemyslaw Bielicki
> >>>> <pbielicki_at_gmail.com> wrote:
> >>>>>>
> >>>>>> 1. Do we rellly want to specify ordering of POJO fields based on
> >>>>>> lexicographic order of field names?
> >>>>>> I think better rely on fields order of appearance in class as it
> done
> >>>>>> in Gson.
> >>>>>
> >>>>>
> >>>>> Eugen is completely right here. The order is nor guaranteed in
> runtime.
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2. Inheritance, order of fields. Should we specify default order of
> >>>>>> fields when using inheritance? Which field set is to be first -
> fields of
> >>>>>> subclass or fields of superclass? In gson superclass fields go
> first.
> >>>>>
> >>>>>
> >>>>> Good point. As usual let's come up with a reasonable and proved
> default
> >>>>> + @Annotation to override it for advanced users.
> >>>>>
> >>>>>>
> >>>>>> 4. Lets add examples for POJO classes wth Collections/Arrays fields
> >>>>>> (one to many relation).
> >>>>>>
> >>>>>
> >>>>> I think you're more than welcome to commit you changes :)
> >>>>>
> >>>>> Cheers,
> >>>>> Przemyslaw
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>