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