On 23.02.15 19:44, Inderjeet Singh wrote:
> 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.
Type is something that JSON Binding will likely have to support in some
way or another to integrate with JAX-RS, so to me it seems more natural
than coming up with any implementation of type tokens.
> Are there plans for a JSR for TypeToken kind of facility in Java?
AFAICT there were some original plans for reified generics which at the
very minimum would clarify some runtime usecases or potentially more,
though that is certainly out of scope of this JSRs requirements (JDK8)
and would not come sooner than JDK9 (or even later). I reached out for
some clarification on the plans there, but don't have any info so far.
MartiNG
> Inder
>
> On Mon, Feb 23, 2015 at 9:25 AM, Martin Grebac
> <martin.grebac_at_oracle.com <mailto: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>
> <mailto: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>
> <mailto: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
>