> It was already discussed couple of times however why not support JVM params to specify JSON-B Provider to be used in runtime similar to specifying TransformerFactory impl in JAXP for example? It might be usefull in some cases and will preserve consistency with other specs. Imagine you have couple of provider libs in classpath and would like in runtime to specify which one to use without recompiling/rebuilding project. How can we cover this use case with specific JsonbConfig as some of you suggested?
I think it was me :) You can provide your own implementation of
JsonbConfig taking configuration from system/environment properties.
Or from database, or distributed cache, or whatever you like. Does it
sound reasonable / feasible?
On Thu, Feb 26, 2015 at 11:31 AM, Oleg Tsal-Tsalko
<oleg.tsalko_at_gmail.com> wrote:
> Hi guys,
>
> We (Kiev UA JUG) come up with list of comments/questions/suggestions reg
> Runtime API proposed so far:
>
> Having pluggable JsonbProviders, do we really want to leave an option to
> also setup diff JsonProviders via JsonBuilder#withProvider(...) method?
> Specific JsonbProvider could decide what JsonProvider to use underneath by
> itself? Such a mix brings a lot of confusion and introduces dependency to
> JSON-P api. We would vote to remove JsonBuilder#withProvider(...) method.
> WDYT?
> Don't we want to add fallback option to JsonbProvider#provide(String
> className) method to load class directly using ClassLoader if no class found
> using ServiceLoader similar to default JsonbProvider#provide() method?
> It was already discussed couple of times however why not support JVM params
> to specify JSON-B Provider to be used in runtime similar to specifying
> TransformerFactory impl in JAXP for example? It might be usefull in some
> cases and will preserve consistency with other specs. Imagine you have
> couple of provider libs in classpath and would like in runtime to specify
> which one to use without recompiling/rebuilding project. How can we cover
> this use case with specific JsonbConfig as some of you suggested?
> From my point of view JsonConfig objects should be thread-safe and immutable
> to be safelly passed around. From the other hand in order to contruct
> JsonbConfig instances we can use implicit inner class builder with
> comprehensive builder methods. See example in attach or on GitHub -
> https://github.com/olegts/jsonb-spec/blob/simplified_api/api/src/main/java/javax/json/bind/JsonbConfig.java
> JsonbConfig properties/methods naming could be improved to be more readable
> and follow builder style. See JsonbConfig class in attach. From client code
> it will looks like:
>
> JsonbConfig config =
> jsonbConfig().withInputEncoding(UTF_16).withPrettyOutput().build();
> instead
> JsonbConfig config = new JsonbConfig()
> .fromJsonEncoding(StandardCharsets.UTF_16.name()) .toJsonFormatting(true);
>
> wsrgeg
>
>
> 2015-02-24 17:53 GMT+02:00 Martin Grebac <martin.grebac_at_oracle.com>:
>>
>> 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
>>
>