0

Using Guava 14.0 with GWT RPC 2.5.1-rc1, built with maven as described in Guava libraries and GWT

Deserialization of Guava collections seems to be working fine. I have however run into a SerializationException when trying to deserialize a response DTO containing an Optional.Present.

Caused by: com.google.gwt.user.client.rpc.SerializationException: com.google.common.base.Present/3434853995
at    com.google.gwt.user.client.rpc.impl.SerializerBase.getTypeHandler(SerializerBase.java:153)

Looking at the SerializerBase.java:146 the methodToJava map does not contain:

com.google.common.base.Present/3434853995

It does however contain a CustomFieldSerializer for:

com.google.common.base.Present/3491224270

So, what is up with the /3434853995 mapping?

It would seem like this is the hash (computed at compile-time) that SerializerBase use to make sure the server side type is the same as the client side type. Looking at the guava-gwt and the server side guava Optional.Present, these do not match. And since the Present is instantiated at the server side, its hash is not matching the client side Present?

Community
  • 1
  • 1
aelgn
  • 821
  • 1
  • 11
  • 17

1 Answers1

1

Hmm. Our internal tests can successfully GWT serialize a server-created Optional, but this wouldn't be the first time that our public Guava release failed to match our internal GWT behavior.

From the link you gave, it sounds like you've already done the first two things I would suggest: make sure that your client- and server-side libraries both depend on guava-gwt, and declare dependency on com.google.common.base.Base in your GWT module.

The other idea I have at the moment is to ask what your DTO looks like. GWT sometimes has trouble identifying which classes it needs to be prepared to serialize. Really, I doubt that that's the problem here: GWT clearly has some inkling that it might need to serialize Present, and anyway, these problems usually arise only with final fields, which would probably cause you more fundamental difficulties.

You might also ensure that you aren't pulling in a different version of Guava transitively somehow. If it's a true Maven transitive dependency, then I think Maven will error out, but if one of your dependencies is bundling the Guava classes directly into its jar, then Maven probably won't notice. This seems unlikely, too, but I'm grasping at straws.

Failing all that, if you can put together a test case that I could run locally, I could investigate further.

Chris Povirk
  • 3,738
  • 3
  • 29
  • 47