New TypeToken in common.reflect and Gson

[Grzegorz Rożniecki]

While digging into r12 sources and Release12 on Wiki, I've noticed TypeToken and whole common.reflect package is introduced into Guava. There is similar (but poorer) TypeToken class in Gson, which I also use. 

Does it mean there is an option that Gson will (or could) depend on Guava or there will be two independent TypeToken classes in Google's codebase?

Until now I had to include TypeAdapters and GsonTypes to serialize ImmutableCollections to Gson, depending on Guava could make Immutable* TypeAdapters easier to include in Gson. (These classes are from Plexi Project and have a comment "An extension of $Gson$Types to get generalized parameter types. This has been submitted to the Gson project; if accepted this file can be removed." but whether or not it will be included to Gson is another question and it probably should be asked onon google-gson list.)

[Louis Wasserman]

https://plus.google.com/106557483623231970995/posts/4JDRy1vfLAK

Jesse Wilson implied that they're interoperable, though I'm not 100% sure how that works?

Louis Wasserman
wasserm...@gmail.com
http://profiles.google.com/wasserman.louis

2012/4/5 Grzegorz Rożniecki <xaer...@gmail.com>

While digging into r12 sources and Release12 on Wiki, I've noticed TypeToken and whole common.reflect package is introduced into Guava. There is similar (but poorer) TypeToken class in Gson, which I also use. 

Does it mean there is an option that Gson will (or could) depend on Guava or there will be two independent TypeToken classes in Google's codebase?

Until now I had to include TypeAdapters and GsonTypes to serialize ImmutableCollections to Gson, depending on Guava could make Immutable* TypeAdapters easier to include in Gson. (These classes are from Plexi Project and have a comment "An extension of $Gson$Types to get generalized parameter types. This has been submitted to the Gson project; if accepted this file can be removed." but whether or not it will be included to Gson is another question and it probably should be asked onon google-gson list.)

--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")

[Kevin Bourrillion]

+Jesse, who is our bridge between these two projects.

--

guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")

--
Kevin Bourrillion @ Google

Java Core Libraries Team
http://guava-libraries.googlecode.com

[limpb...@gmail.com]

On Thursday, April 5, 2012 11:49:52 AM UTC-4, Grzegorz Rożniecki wrote:

Does it mean there is an option that Gson will (or could) depend on Guava or there will be two independent TypeToken classes in Google's codebase?

Gson's TypeToken was forked from Guava's TypeToken in 2008. They've each received four years of independent development. In that time:

• Guava's TypeToken got vastly improved documentation, type resolution, type hierarchy accessors, and much improved isAssignableFrom() logic.
• Gson's TypeToken saw it's incorrect isAssignableFrom() method deprecated.

Gson's TypeToken is sufficient for what Gson needs it for: identifying a parameterized type like a Map<String, Date>. Guava's TypeToken is more flexible and general purpose, like Guava itself.

 

Until now I had to include TypeAdapters and GsonTypes to serialize ImmutableCollections to Gson, depending on Guava could make Immutable* TypeAdapters easier to include in Gson. (These classes are from Plexi Project and have a comment "An extension of $Gson$Types to get generalized parameter types. This has been submitted to the Gson project; if accepted this file can be removed." but whether or not it will be included to Gson is another question and it probably should be asked onon google-gson list.)

Yeah, that is addressing a problem. Previously where I said that TypeToken was sufficient, I was slightly lying. Gson's built-in type adapters use a few more type-wrangling classes to unpack that Map<String, Date> into its components. Applications that include similarly flexible type adapters will need similarly flexible type wrangling utilities.

My recommendation is for such applications to just use Guava's TypeToken for type wrangling.

You can interoperate using 'getType()' and 'get()', like so:

  com.google.gson.reflect.TypeToken<?> gsonTypeToken = new com.google.gson.reflect.TypeToken<List<String>>() {};

  com.google.common.reflect.TypeToken<?> guavaTypeToken = com.google.common.reflect.TypeToken.get(gsonTypeToken.getType());

This also works with Guice's TypeLiteral, the third triplet in the lot.

Cheers,

Jesse