Don't force them, but let them use the library of their choice (Guava,
Johnzon or any other) to create a Type object.
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.
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
>>>>>>
>>>>>
>>>>>
>>>>
>>