OK - that's fine for me. I'm leaning towards only one method e.g.
withEncoding(...)
Regarding pretty printing, I would use the same naming convention as
JSONP. It's always pain in the neck when different APIs call the same
feature differently (e.g. Java Array.length vs. Collection.size())
On Mon, Mar 16, 2015 at 3:24 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com> wrote:
> 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
>> >> >
>> >
>> >
>
>