jsr367-experts@jsonb-spec.java.net

[jsr367-experts] Re: [jsonb-spec users] Re: [30-GenericTypeSupport] Proposal

From: Romain Manni-Bucau <rmannibucau_at_tomitribe.com>
Date: Fri, 13 Mar 2015 11:38:28 +0100

Answered inline

Le 13 mars 2015 08:28, "Inderjeet Singh" <inder_at_alumni.stanford.edu> a
écrit :
>
> Don't force them, but let them use the library of their choice (Guava,
Johnzon or any other) to create a Type object.
>

This is the original issue. For advanced cases (N levels of generics with N
> 1) it is fine but for common cases (N =1) it sounds like a failure. Said
otherwise why using an api which needs another one? Just use the complete
one.

> Using a constructed Type is an advanced use-case anyway. For example,
with Gson, a majority of use-cases get handled without constructing a type
ever.
>

Not fully agree. List and Map are super common (just think to crud). We
can't rely on wrappers as for jaxb for json - just check how many people
get rid of jettison for alternatives cause of it. Just makes it not natural
so parameterized type are as common as classes for me.

> Inder
>
> On Thu, Mar 12, 2015 at 11:49 PM, Romain Manni-Bucau <
rmannibucau_at_gmail.com> wrote:
>>
>> We can't force a user to use a lib - or means the spec is not usable.
>>
>> Can be as simple as providing an implementation like
JohnzonParameterizedType [1] which is trivial but solves this issue for
most of cases - and several of remzining ones can be illegal (type variable
etc).
>>
>> [1]
https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=blob;f=johnzon-mapper/src/main/java/org/apache/johnzon/mapper/reflection/JohnzonParameterizedType.java;h=479268e451b88de3851dce48a97a0f6d29ca3b79;hb=dcc3a2c2a96d095251328740c03ebc0c053077c6
>>
>> - Romain
>>
>> Le 13 mars 2015 07:38, "Inderjeet Singh" <inder_at_alumni.stanford.edu> a
écrit :
>>
>>> My recommendation will be that this API shouldn't provide any
TypeLiteral.
>>> For the users who need that support, should use Guava in conjunction
with this.
>>>
>>> Inder
>>>
>>>
>>> On Thu, Mar 12, 2015 at 2:50 PM, Romain Manni-Bucau <
rmannibucau_at_tomitribe.com> wrote:
>>>>
>>>> Hi
>>>>
>>>> Type is really powerful but has one drawback: it is not working out of
the box. This means we need to add a reflect package with basic
implementations of some types in the api to make it a smooth api - at least
ParameterizedType and maybe a list/set/map ones cause it is very common.
Next issue we could hit is then we depend in the api of the jvm indirectly
- interfaces get new method with jvm versions sometimes so what we can do
is really bound to a jvm.
>>>>
>>>> That said i like the fact it avoids to introduce a new api and yet
another type literal but just some common helper classes.
>>>>
>>>> - Romain
>>>>
>>>> Le 12 mars 2015 18:53, "Inderjeet Singh" <inder_at_alumni.stanford.edu> a
écrit :
>>>>
>>>>> For Gson, we started with Type for pretty much the same reasons. Also
because most developers are familiar with Type, and TypeLiteral is a
new/advanced concept.
>>>>>
>>>>> Gson uses <T> T fromJson(String, Type) to avoid the need for
casting. But it is unsafe, as you point out.
>>>>> In practice though, I have not seen it to be a problem.
>>>>>
>>>>> TypeLiteral are very useful in JSON conversion, so we did end up
adding it to Gson. Once we added it, I would have liked to revise
fromJson() methods to use TypeLiterals instead of Type. But we couldn't do
that for backward compatibility reasons.
>>>>>
>>>>> So, the point really is that if TypeLiterals are going to be added in
a JSR, then it is better for JsonB to depend on that JSR and use
TypeLiterals.
>>>>>
>>>>> But if you can't depend on the TypeLiteral JSR (if any), then go
ahead and use Type. It works just fine.
>>>>>
>>>>> Inder
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 12, 2015 at 9:51 AM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
wrote:
>>>>>>
>>>>>> Hey Martin,
>>>>>>
>>>>>> 2015-03-12 17:21 GMT+01:00 Martin Vojtek <voytoo_at_gmail.com>:
>>>>>>>
>>>>>>> Hi Experts,
>>>>>>>
>>>>>>> I would like to open discussion about Generic Type Support in JSON
Binding.
>>>>>>>
>>>>>>> The initial proposal is to add two methods to Jsonb interface:
>>>>>>>
>>>>>>> public <T> T fromJson(String str, java.lang.reflect.Type
runtimeType) throws JsonbException;
>>>>>>>
>>>>>>> public String toJson(Object object, java.lang.reflect.Type
runtimeType) throws JsonbException;
>>>>>>>
>>>>>>> (and analogically other methods with different input/output)
>>>>>>>
>>>>>>> Based on reviewing existing options, it does not appear there is a
single optimal option.
>>>>>>>
>>>>>>> Reasoning behind java.lang.reflect.Type.
>>>>>>>
>>>>>>> There are several ways how to deal with generics:
>>>>>>>
>>>>>>> 1. To use java.lang.reflect.Type
>>>>>>> 2. Use Type Literal (e.g. GenericType ...)
>>>>>>> 3. Use Generic Type Builder
>>>>>>>
>>>>>>> It would be a lot of unnecessary code to build Generic Type
Builder. And I think this should be not part of JSON Binding.
>>>>>>>
>>>>>>
>>>>>> I agree with you.
>>>>>>
>>>>>>>
>>>>>>> Type Literal may work in some cases, but generally it doesn't work
(in infinite cases). It is also not backed by Java Language Specification
and may not work in the future. For example, Type Literal doesn't work when
used with lambdas or with some JVM languages different than Java.
>>>>>>
>>>>>>
>>>>>> I understand but I think that it works in most use cases where it is
needed. People use it to just deal with basic generics (custom or std
types).
>>>>>>
>>>>>>>
>>>>>>> I don't want to introduce yet another GenericType class and to
duplicate code with some other specifications.
>>>>>>
>>>>>>
>>>>>> I agree it is ugly :( would have been better if there was a similar
thing as TypeToken from guava in std java (even if it is a hack in some
way).
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Use of java.lang.reflect.Type seems like the best choice from bad
choices available. Integration with JAX-RS will be flawless, it is upon the
user to build java.lang.reflect.Type (hopefully with the help of JSON
Binding implementation).
>>>>>>>
>>>>>>> User can use already available Type Literal classes available in
the Java ecosystem.
>>>>>>
>>>>>>
>>>>>> Good point and most people already use guava. Only downside will be
the untyped result of the fromJson.
>>>>>> Here we can avoid user cast by doing : <T> T fromJson(String, Type),
but it is definitely unsafe.
>>>>>>
>>>>>> Might be interesting to have Inderjeets feedback on how it was when
they were using type and TypeToken.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Examples and pdf proposal are available at
>>>>>>>
>>>>>>>
https://java.net/projects/jsonb-spec/sources/git/content/spec/spec.pdf?rev=da7db533076856699cec49a4eebd300b9f4a7230
>>>>>>>
>>>>>>>
https://github.com/json-binding/spec/blob/default_mapping/examples/runtime/src/main/java/examples/mapping/DefaultMappingGenerics.java
>>>>>>>
>>>>>>> Looking forward to your feedback.
>>>>>>>
>>>>>>> MartinV
>>>>>>
>>>>>>
>>>>>
>>>
>