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