Hi guys,
We (Kiev UA JUG) come up with list of comments/questions/suggestions reg
Runtime API proposed so far:
1. 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?
2. 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?
3. 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?
4. 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
5. 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);
6. 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
>
>