You can avoid TypeToken by using j.l.r.Type instead. But because Type is
not parameterized, you lose all the type-safety benefits of TypeToken. In
Gson, we went back and forth on this (I was in favor of Type instead of
TypeToken initially).
In hindsight, I think TypeToken is better. The practical use-cases are just
too numerous where you have to construct a Type object in code. You should
also look at a robust TypeToken implementation similar to Guava that let's
you construct type in many different ways.
Are there plans for a JSR for TypeToken kind of facility in Java?
Inder
On Mon, Feb 23, 2015 at 9:25 AM, Martin Grebac <martin.grebac_at_oracle.com>
wrote:
> So, seems like we naturally converged to the generics / typetoken /
> literal / ... discussion which I wanted to avoid and open it separately
> within https://java.net/jira/browse/JSONB_SPEC-30 :)
>
> Still plan to open/branch the discussion separately likely this week to
> not spoil runtime/mapping topics with it, but here's some hints into the
> thinking since we're at the topic already:
>
> I don't feel like adding X times Y list/map specific methods into the api
> brings much value compared to the complexity it adds.
>
> The trouble with TypeTokens/Literals/Gafter's gadget/... aproach is that
> those are just a different versions of the same side-effect - they are not
> guaranteed to work. They happen to work because of the JDK internal
> requirements, but there's no base for it in the Java language specification
> and we should not be building other APIs on side-effects. One place this
> has been discussed already is at [1], raised by Pavel Bucek after a long
> discussion with Brian Goetz. I'd recommend to read/evaluate this through.
> Generics in Java were designed for compile-time, not for runtime - and
> should be used as such.
>
> MartiNG
>
> [1] https://java.net/projects/websocket-spec/lists/jsr356-
> experts/archive/2014-05/message/0
>
>
> On 23.02.15 10:04, Przemyslaw Bielicki wrote:
>
>> Hi Eugen,
>>
>> thanks a lot for complete example! I think we should go TypeToken way.
>>
>> Przemyslaw
>>
>> On Sun, Feb 22, 2015 at 6:56 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com
>> <mailto:cepoi.eugen_at_gmail.com>> wrote:
>>
>> fromJson(json, MyPojo.class) returns an instance of MyPojo, no
>> need to cast.
>> How to deser to a list of MyPojo (or any other generic type)?
>>
>> List<MyPojo> fromJson(json, new TypeToken<List<MyPojo>>() {})
>>
>> An example of impl
>> https://github.com/owlike/genson/blob/master/genson/src/
>> main/java/com/owlike/genson/GenericType.java
>>
>> You can also have a look at guavas Typetoken impl which is more
>> sophisticated.
>>
>> This should avoid all kind of casts when the user knows what the
>> actual type should be.
>>
>> Le 22 févr. 2015 00:17, "Przemyslaw Bielicki" <pbielicki_at_gmail.com
>> <mailto:pbielicki_at_gmail.com>> a écrit :
>>
>> Hi,
>>
>> Yes these methods are a bit redundant, I agree.
>> Do you have better idea how to avoid casts and
>> @SuppressWarnings("unchecked") annotation? Can we achieve this
>> using combination of Class and TypeToken? Because forcing end
>> users to do so (casts and suppress) stinks in a modern API.
>>
>> I have one more comment regarding POJO but don't have time to
>> express myself ;)
>>
>> Stay tuned,
>> Przemyslaw
>>
>> --
> Martin Grebac, SW Engineering Manager
> Oracle Czech, Prague
>
>