jsr367-experts@jsonb-spec.java.net

[jsr367-experts] Re: [jsonb-spec users] Re: Re: [1-RuntimeAPI] Proposal

From: Eugen Cepoi <cepoi.eugen_at_gmail.com>
Date: Thu, 19 Feb 2015 14:12:08 -0800

Hi Hendrik,

2015-02-19 13:42 GMT-08:00 Hendrik Dev <hendrikdev22_at_gmail.com>:

> Hi Martin, Hi Experts,
>
> sorry for delay, here are my comments and patches:
>
> 1) Do we really need a JSONB_FROMJSON_ENCODING and if yes whats the
> default? According to RFC 4627 JSON is must always be Unicode and the
> encosing can therefore be always be detected by the algo described in
> chapter 3.
>
> 2) Jsonb.java: Do we also want to add java.nio andy byte[] support here?
>

At least byte[] is an useful shortcut, many frameworks where you pass in
event data or columnar stores take/return raw byte[] values.


>
> 3) Jsonb.java: Suggest to change Class<T> to Type for the fromJson()
> methods to support generic types. (JSONB_SPEC-30)
>
>
Using class<T> provides type safety, for generics using some kind of
TypeToken<T> (that holds the generic type) should answer to both problems.
Also getting a java.lang.reflect.Type is kind of boilerplate, thus I guess
most end users won't provide it - instead they would like to build it using
the TypeToken trick. I think both should be there, raw class and some way
to pass the generic type (not in the same method of course).


> 4) @Przemyslaw: System properties? later you said trolling, hope so :-)
>
> 5) Interface approach: Id like to see interfaces (over classes) since
> implementations have to also "implement" the spec jars (depending on
> licesing stuff), so its not helpful here to try to solve things in the
> spec jars once and forever. It makes it even harder because if to much
> code and classes are in the spec the distinction between spec and impl
> will get vague and spec gets bloated (if you're looking for a good
> example see javamail/JSR-919).
>

I guess it depends...I would prefer to have the spec do more stuff than
just providing some interfaces but I get your point.
The advantage of providing few contracts (like the Jsonb interface and then
no Serializer/Deserializer interface to impl, no wiring etc) makes the work
for implementors easy.
Lets wait and see.

Cheers,
Eugen


>
> 6) Patches: https://github.com/salyh/spec/commits/salyh_fixes1 (or
> maybe better attach it to the mail as .diff?)
>
> General:
> I'd like to create a simple (but yet powerful) api since JSON itself
> is simple but powerful. So i agree not to rebuild JAXB for JSON cause
> XML is not JSON.
> As one who has implemented JSR 353 i am glad to see no factories in
> the current runtime api proposal. I'd like the builder and immutable
> 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 :-)
>
> BTW: Do i have missed the round of introductions?
>
> 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
>