jsr367-experts@jsonb-spec.java.net

[jsr367-experts] Re: [2-DefaultMapping] Proposal

From: Eugen Cepoi <cepoi.eugen_at_gmail.com>
Date: Mon, 16 Mar 2015 15:24:58 +0100

It is, but still rare. From what I have seen with Genson, most people
deser. the same way they serialize.
In that case one can just configure two different Jsob instances.

2015-03-16 14:40 GMT+01:00 Przemyslaw Bielicki <pbielicki_at_gmail.com>:

> just wondering if use case where you receive utf-8 and want to
> serialize to iso-8859-1 is impossible?
>
> On Mon, Mar 16, 2015 at 2:34 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
> wrote:
> > Oh you prefer the ability to configure separately ser and deser??
> > I am in favor of not doing so and just have withEncoding(..)
> >
> > 2015-03-16 14:27 GMT+01:00 Przemyslaw Bielicki <pbielicki_at_gmail.com>:
> >>
> >> +1 for readEncoding and writeEncoding
> >>
> >> On Mon, Mar 16, 2015 at 2:24 PM, Martin Grebac <
> martin.grebac_at_oracle.com>
> >> wrote:
> >> > On 16.03.15 14:09, Eugen Cepoi wrote:
> >> >>
> >> >> 2015-03-16 13:54 GMT+01:00 Martin Grebac <martin.grebac_at_oracle.com
> >> >> <mailto:martin.grebac_at_oracle.com>>:
> >> >>
> >> >> On 12.03.15 17:36, Eugen Cepoi wrote:
> >> >>
> >> >> Hey Martins,
> >> >>
> >> >> Quick feedback on the API.
> >> >>
> >> >> I don't like much the to/from in JsonbConfig. At least for
> the
> >> >> formatting it is obvious that it exists only during
> >> >> serialization.
> >> >>
> >> >> What would be the suggestion?
> >> >>
> >> >>
> >> >> When the config is valable only for ser or deser, just use the config
> >> >> name
> >> >> (+ maybe some prefix use/with/etc). And about configs that exist for
> >> >> both
> >> >> ser and deser I am not sure. I hesitate between:
> >> >> - don't allow to configure a same instance with different ser and
> >> >> deser
> >> >> configs => we can then use the same naming strategy as previously
> >> >
> >> > There are implementations which allow this to be configured
> separately,
> >> > but
> >> > I still find very little benefit in it. This seems like a rare case
> and
> >> > you
> >> > can achieve the same with 2 differently configured Jsonb instances. My
> >> > vote
> >> > would be to not allow this, in my local changes I'd change this to
> >> > withEncoding, withFormating.
> >> >
> >> >> - provide the ability to configure separately ser/de => prefix with
> >> >> serializationEncoding/deserializationEncoding
> >> >
> >> > If, then I'd prefer something shorter, like readEncoding and
> >> > writeEncoding.
> >> >
> >> >> - keep as it is
> >> >>
> >> >> toJson/fromJson look a bit strange as they are "active terms",
> working
> >> >> well when doing the action in Jsonb but less for configuration,
> that's
> >> >> probably why I don't like it much. What do others think?
> >> >
> >> > Agree with the active term, this needs correction.
> >> >
> >> > MartiNG
> >> >
> >> >
> >> >>
> >> >> Not sure ConfigException is needed, I mean sure in some case
> >> >> we could throw this exception, but in practice maybe no one
> >> >> will. Also in multiple places I see IllegalArgumentEx, and it
> >> >> makes sense, we could same way use other existing exceptions
> -
> >> >> instead of ConfigEx.
> >> >> getProperty could return an Optional and throw an exception
> >> >> only if the arg is null.
> >> >>
> >> >> Both sound good to me, will apply unless hear otherwise.
> >> >>
> >> >> We could also add an option to skip null during serialization
> >> >> in the config.
> >> >>
> >> >> We'll handle this separately, but I agree.
> >> >>
> >> >> In JsonbBuilder, the newBuilder related to JsonbProvider are
> a
> >> >> bit redundant as we also have similar method inside the
> >> >> provider. But from another side, it provides a single entry
> >> >> point - this is good. This makes the API more easy to use.
> >> >>
> >> >> I didn't read the javadoc carefully.
> >> >>
> >> >> About the examples... well they are just examples :)
> >> >>
> >> >> That's why I'd like to focus you more on the spec pdf itself at
> >> >> this point ;)
> >> >> MartiNG
> >> >>
> >> >>
> >> >> Eugen
> >> >>
> >> >>
> >> >> 2015-03-12 16:46 GMT+01:00 Martin Grebac
> >> >> <martin.grebac_at_oracle.com <mailto:martin.grebac_at_oracle.com>
> >> >> <mailto:martin.grebac_at_oracle.com
> >> >>
> >> >> <mailto:martin.grebac_at_oracle.com>>>:
> >> >>
> >> >> Just would like to explicitly point to the spec document
> >> >> itself in
> >> >> this branch:
> >> >>
> >> >>
> >> >>
> >> >>
> https://java.net/projects/jsonb-spec/sources/git/content/spec/spec.pdf?rev=da7db533076856699cec49a4eebd300b9f4a7230
> >> >>
> >> >> MartiNG
> >> >>
> >> >>
> >> >> On 12.03.15 16:35, Martin Vojtek wrote:
> >> >>
> >> >> Hi Experts,
> >> >>
> >> >> there has been a lot of changes recently in
> >> >> default_mapping.
> >> >> This completes the second iteration of default
> mapping
> >> >> proposal.
> >> >>
> >> >> Generics and integration with JSON Processing is not
> >> >> part of
> >> >> this discussion.
> >> >>
> >> >> Please take a look and feel free to express your
> point
> >> >> of view.
> >> >>
> >> >> https://github.com/json-binding/spec/tree/default_mapping
> >> >>
> >> >> Looking forward to your feedback.
> >> >>
> >> >> MartinV
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> -- Martin Grebac, SW Engineering Manager
> >> >> Oracle Czech, Prague
> >> >>
> >> >>
> >> >
> >> > --
> >> > Martin Grebac, SW Engineering Manager
> >> > Oracle Czech, Prague
> >> >
> >
> >
>