@Hendrik - no I was serious about system / environment properties because
this is a common way of overriding compiled properties/settings in
different test and (pre)production environments. I also proposed a
specialized JsonbConfig interface which is more generic approach, thus
system properties can be considered as a dead-issue (or trolling if you
prefer ;)
As I said before - I'm a supporter or the opinion that API should contain
only interfaces and exception classes. I'm open for some extremely useful
exceptions to this rule but all the ppl here should be aware that changing
something in RI will be quick and easy while if we make mistake or want to
change anything in the API classes it might take months (even for simple
change) because of JCP process.
I think you should post your diffs as email attachment. I prefer github but
as I understand we are not going to use it for this project, so we have to
get used to pure git.
Cheers,
Przemyslaw
On Thu, Feb 19, 2015 at 10:42 PM, Hendrik Dev <hendrikdev22_at_gmail.com>
wrote:
> 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?
>
> 3) Jsonb.java: Suggest to change Class<T> to Type for the fromJson()
> methods to support generic types. (JSONB_SPEC-30)
>
> 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).
>
> 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
>