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