jsr367-experts@jsonb-spec.java.net

[jsr367-experts] Re: [jsonb-spec users] Re: Re: [33-I-JSON Compatibility] Proposal

From: Eugen Cepoi <cepoi.eugen_at_gmail.com>
Date: Mon, 20 Apr 2015 19:34:00 +0200

2015-04-20 19:28 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:

> well not supporting the validation for custom serialization code
> doesnt sound like a big issue for me but it doesn't prevent to
> validate the model. I didn't speak of the merging but for instance 2
> different methods/fields decorated with @JsonProperty(name="foo").
>

Yes I was including renamed properties in that and by merging I was meaning
take N properties (field/method/ctr) and reduce it to one (how you achieve
it is up to the impl).
To me renamed or original name is the same, as I first resolve the names
and then do all the selection/merging stuff.
Amongst others, this allows to override in subclasses things from parent
classes - by using the same name.


>
> For me just doing it already matches the intention behind I-JSON.
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-04-20 19:24 GMT+02:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
> > I think doing it on the model is something else as basically you already
> > merge detected properties, so you end up with only one.
> > At least that's what I do in Genson, I give preference to the detected
> > properties (methods/fields/whatever else) by hierarchy (from most
> concrete
> > to the "highest" parent). And the compiler provides already some
> safeguards.
> >
> > Still all that doesn't solve the problem of colliding properties being
> > written by the user (via some custom ser. code).
> > But well... we can't always prevent people from doing stupid things :)
> >
> > 2015-04-20 19:11 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
> >>
> >> 2015-04-20 19:05 GMT+02:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
> >> >
> >> > 2015-04-19 19:44 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
> >> >>
> >> >> Hi Martin
> >> >>
> >> >> for me it makes sense to support it by default with a flag like the
> >> >> one you proposed to switch it off (a bit off topic but do we have
> >> >> constants for these flags, something like Jsonb.I_JSON_COMPLIANCE?).
> >> >>
> >> >> UTF8 by default is quite mandatory IMO, must-ignore as well (already
> >> >> discussed IIRC). ISO8601 is the standard for dates of most of
> >> >> frameworks, big numbers need to be string whatever we do so finally
> >> >> open points from my window are:
> >> >>
> >> >> - byte data as base64: on johnzon we discussed it and I didn't want
> it
> >> >> cause it was far from Java - that said it is not a super common type
> >> >> so not sure it is that important
> >> >> - top level construct: don't recall the spec but I think primitives
> >> >> (string, numbers) can be supported as well. Jackson does it at least
> >> >> so +1 to not support this fail fast behavior
> >> >
> >> >
> >> > I don't think there is much value in being too restrictive, +1 for it.
> >> > I don't remember any discussion about accepting to deser. numbers as
> >> > strings, strings as numbers etc when possible, but it would be nice.
> >> >
> >> >>
> >> >> - no members with duplicate name: the only point I don't know.
> >> >
> >> >
> >> > This one is painful as it has an impact on performances (esp. if we
> want
> >> > to
> >> > prevent user custom code to generate such output)... at the moment I
> >> > don't
> >> > support it in Genson for this reason.
> >> >
> >>
> >> Can't we do it on the model (ie once for the whole application
> >> lifecycle)? I guess here we are lucky compared to JSON-P.
> >>
> >> >>
> >> >> Intellij Idea makes this kind of JON invalid. This is something we
> >> >> would need to be able to switch off but I think it makes sense to
> have
> >> >> it by default to detect wrong models.
> >> >>
> >> >>
> >> >> Romain Manni-Bucau
> >> >> @rmannibucau
> >> >> http://www.tomitribe.com
> >> >> http://rmannibucau.wordpress.com
> >> >> https://github.com/rmannibucau
> >> >>
> >> >>
> >> >> 2015-04-18 19:53 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
> >> >> > Hi Experts,
> >> >> >
> >> >> >
> >> >> > JSON-B should provide support or some level of compliance with
> I-JSON
> >> >> > specification.
> >> >> >
> >> >> > https://tools.ietf.org/html/rfc7493
> >> >> >
> >> >> > There are several things to discuss.
> >> >> >
> >> >> > Should JSON-B support I-JSON by default? My proposal is to not
> >> >> > support
> >> >> > all
> >> >> > the recommendations of I-JSON by default.
> >> >> >
> >> >> > If we agree on that, what specific parts of I-JSON should JSON-B
> >> >> > provide
> >> >> > by
> >> >> > default?
> >> >> >
> >> >> >
> >> >> > Proposal of parts (of I-JSON) to support by JSON-B by default:
> >> >> >
> >> >> > Should be supported by default:
> >> >> > - Encoding and Characters (UTF-8 by default)
> >> >> > - Object constraints (no members with duplicate name)
> >> >> > - MUST-IGNORE policy - partial mapping
> >> >> > - Time and Date Handling - serialize accoring to I-JSON
> >> >> >
> >> >> > Should not be supported by default:
> >> >> > - Numbers - serialize big number(s) into string (and deser given
> >> >> > strings
> >> >> > into number)
> >> >> > - Top-Level Constructs - fail fast when ser/deser something
> different
> >> >> > than
> >> >> > object/array as top-level JSON
> >> >> > - binary data encoded as a string in base64url
> >> >> >
> >> >> >
> >> >> > To support I-JSON fully in some case, I propose to provide I-JSON
> >> >> > compatibility mode available via config property.
> >> >> >
> >> >> > JsonbConfig config = new
> >> >> > JsonbConfig().setProperty("jsonb.i-json.compliance", true);
> >> >> > Jsonb jsonb = JsonbBuilder.create(config);
> >> >> >
> >> >> > Looking forward to your feedback.
> >> >> >
> >> >> > MartinV
> >> >
> >> >
> >
> >
>