Hi Hendrik,
approach cause with some sensitive default shortcuts. I aggree with
> Inderjeet that Jsonb() should be sufficient the most use cases. I do
> NOT aggree with Inderjeet when he says
>
> "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."
>
> cause thats a) not true and b) if you mean with default implementation
> the RI then this is also not true. RI has IMHO a total other emphasis
> than other non-RI implementations (and of course other licenses :-).
> Inder, maybe you can clarify this, thanks :-)
>
I am not sure I fully understand your points here.
What I mean is this: Developers use whichever implementation comes with
their environment.
This JSR may become part of the JDK, and in that case, I don't think we
care about alternate implementations.
>
> BTW: Do i have missed the round of introductions?
>
Not sure, if there was a round of introductions.
For myself, I am the co-author of Gson.
Inder
>
> Kind regards
> Hendrik
>
> On Tue, Feb 10, 2015 at 7:15 PM, Inderjeet Singh
> <inder_at_alumni.stanford.edu> wrote:
> > 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
> >>
> >>
> >
>
>
>
> --
> Hendrik Saly (salyh, hendrikdev22)
> @hendrikdev22
> PGP: 0x22D7F6EC
>