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