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