jsr367-experts@jsonb-spec.java.net

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

From: Romain Manni-Bucau <rmannibucau_at_gmail.com>
Date: Fri, 13 Mar 2015 07:49:33 +0100

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
>>>>>
>>>>
>>>>
>>>
>