On Fri, Feb 20, 2015 at 2:50 AM, Inderjeet Singh
<inder_at_alumni.stanford.edu> wrote:
> 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.
I was not aware of this, is this really the case?
At least for EE i like the provider approach.
>
>>
>>
>> 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.
I am apache committer of Apache Johnzon (JSR 353 impl) which also
provides a json binding (mapper) component.
I am also EG member of JSR 374 (Jsonp 1.1.)
Kind regards
Hendrik
>
> 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
>
>
--
Hendrik Saly (salyh, hendrikdev22)
@hendrikdev22
PGP: 0x22D7F6EC