users@jsonb-spec.java.net

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

From: Martin Grebac <martin.grebac_at_oracle.com>
Date: Tue, 24 Feb 2015 16:53:16 +0100

Yes. I don't see how the provider approach complicates the api, and
given the JSON Binding is filed as a standalone JSR, with inclusion to
Java EE, we just have to support providers. Also circling back to
Inder's previous question, there was a reason to deal with providers in
JAXP world, too - number of applications decided to use Woodstox e.g.
(or even other non O/S providers) to address specific needs.
  MartiNG

On 24.02.15 16:21, Hendrik Dev wrote:
> so this means we keep the provider approach (in the first place) ?
>
> On Mon, Feb 23, 2015 at 4:57 PM, Martin Grebac <martin.grebac_at_oracle.com> wrote:
>> On 20.02.15 10:36, Hendrik Dev wrote:
>>> 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.
>> It may, it may not - with Jigsaw and modularity it may not be that required
>> to grow Java SE too much. The primary goal of this JSR as of this point is
>> certainly Java EE (8).
>>
>> MartiNG
>>
>
>

-- 
Martin Grebac, SW Engineering Manager
Oracle Czech, Prague