Le 10 févr. 2015 09:29, "Martin Grebac" <martin.grebac_at_oracle.com> a écrit :
>
>
> On 08.02.15 19:30, Eugen Cepoi wrote:
>>
>> Some quick comments:
>>
>> In Jsonb javadoc: /"{_at_code toJson}: marshall Java objects content tree
*from JSON input*/" => to json?
>
> Fixed, thanks.
>
>
>> Example 3: could be just: Jsonb jsonb = new CustomJsonbBuilder().build()
no?
>>
>> In the ser/de examples, I would only keep one "Jsonb jsonb =
JsonbBuilder.create()" at the beginning and then refer to jsonb instance,
so it is more obvious than the same instance can and should be reused.
>
> Agree with the above, applied.
>
>
>> JsonBuilder().build() and JsonBuilder.create(), both make a Jsonb
instance but one is static and the other an instance method, maybe they
could have the same name?
>
> Actually, not sure how you would want to achieve it? I left the names
different to distinguish the 'helper' methods from the real builder method.
I just meant to use the same name for the methods that create a jsonb
instance. But making the distinction with the helper method is fine too.
>
>> Lets see what you have in mind and how you are planning to address the
main jira tickets before discussing things more in depth :)
>>
>> - I am most interested in first seeing how *default ser/de* (only for a
couple of types) would be impl and how *end users would plug in custom
ser/de* (only via an Adapter or with direct access to some low level
streaming api). The adapter (pojo <> json object) solution would be fine if
they don't need extra perfs
>>
>> - Then see how types with no default ser/de (JavaBeans ?) would be
handled.
>
> Sure, Martin Vojtek will start bringing the mapping topics to the table
soon and I'll continue with the additional topics which will cover also
those below.
>
> MartiNG
>
>
>> Once here we should have a good feel of the API and have more material
to aliment the discussion :)
>> Then move to:
>>
>> - How visibility, naming strategy, etc would be achieved and used with
the java beans ser/de.
>>
>> - How generics would be handled and integrated with the rest of the API.
>>
>> This should cover the major parts where opinions about the design could
diverge.
>
>