Some quick comments:
In Jsonb javadoc: *"{_at_code toJson}: marshall Java objects content tree from
JSON input*" => to json?
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.
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?
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.
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.
Eugen
2015-02-06 18:30 GMT+01:00 Inderjeet Singh <inder_at_alumni.stanford.edu>:
> Hi Martin,
>
>
>> 1. How about replacing Jsonb with Json everywhere in the API? Json is
>>> shorter and easier to understand. "b" doesn't necessarily make sense from a
>>> developer's perspective.
>>>
>> I actually ran through several different iterations before: 'Json',
>> 'Jsonb', 'JsonBind', 'JsonBinding'. Though, I found 'JsonBind' and
>> 'JsonBinding' unnecessarily long, and simple 'Json' clashes with JSON-P. It
>> is going to be a usual case to have JSON-P and JSON-B code to be mixed
>> together in the same class/method so it will cause a lot of confusion.
>
>
> Ok. I wasn't actually aware of the JSON-P APIs. As a developer, I would
> expect the APIs to work seamlessly, so some mixing may actually be
> desirable.
>
> 2. JsonBuilder.create() and newBuilder() methods seem unnecessary to me.
>
>> new JsonBuilder() has much less conceptual weight as everyone understand
>>> what "new" does.
>>> 3. I think we should get rid of Providers. They don't add any value from
>>> a developer's perspective. If you really want it, add an SPI.
>>>
>> I think the 2 above are connected, though I'm not sure I'm able to create
>> the full picture. Would you share more details on this?
>>
>
> From my experience designing Gson API, I think the developers care about
> two things:
> 1. Instantiate and configure a Gson instance. Actually, I don't even like
> builders all that much.
> new Gson() provides all the sensible defaults and GsonBuilder is meant
> only for advanced customizations. In practice, we made a few mistakes in
> selecting defaults for Gson (incorrect default date format, permissible
> deserialization, etc.), so using the GsonBuilder is often necessary.
>
> Since JsonB API is starting from scratch, it should learn from our
> mistakes, and have a really good "new Jsonb()"implementation.
>
> 2. Use the Gson instance. Here the primary concern is ease-of-use
> (toJson/fromJson), and ability to handle advanced use-cases (generic types,
> type variables, collections, etc.). Additional concerns are runtime
> performance, and thread-safety.
>
> There is typically NO developer concern about plugging in an alternate
> implementation. So, we should just have a really good default
> implementation and get rid of providers.
>
> Inder
>
>
>