Hi Martin,
I am not saying that builder shouldn't be available. I am saying that the
default options should be so good that new Jsonb() should be sufficient in
most cases. Builder should be left for customizations.
JavaEE may be your goal, but JavaSE + Web stack is what is ruling the
developer world today. For this JSR to be widely used, improving
experience with Java SE should be the primary goal. For Java EE, provide
some advanced provider API that most developers don't have to see.
(I used to be a JavaEE guy too (at Sun), but never quite saw the providers
being all that useful. How often have people in this group really needed to
use the providers in JAXP?)
Inder
On Tue, Feb 10, 2015 at 9:11 AM, Martin Grebac <martin.grebac_at_oracle.com>
wrote:
> Hi,
> thanks, understood, though I'd consider Builder to not be a complicated
> structure even for beginners. We'll get to the advanced usecases, I'll be
> bringing up generic types discussion soon, I'm expecting lots of fun on
> this topic ;O). I understand the point on providers, too, that goes more
> towards Java SE world, where there's usually one implementation which rules
> it all. Java EE world uses a different concept, where providers are (more
> or less) needed, even though in the end it may turn out there is going to
> be just a few real implementations.
> MartiNG
>
>
> On 06.02.15 18:30, Inderjeet Singh wrote:
>
>> 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
>>
>
>