使用Guava 14.0和GWT RPC 2.5.1-rc1，使用maven构建，如Guava libraries and GWT
中所述Guava集合的反序列化似乎工作正常。但是，在尝试反序列化包含Optional.Present的响应DTO时，我遇到了SerializationException。
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)
查看SerializerBase.java:146，methodToJava地图不包含：
com.google.common.base.Present/3434853995
但它包含一个CustomFieldSerializer：
com.google.common.base.Present/3491224270
那么，/ 3434853995映射是什么？
看起来这是hashizerBase用来确保服务器端类型与客户端类型相同的散列（在编译时计算）。 看看guava-gwt和服务器端guava Optional.Present，这些都不匹配。并且由于Present在服务器端实例化，其哈希值与客户端Present不匹配？
答案 0 :(得分：1)
嗯。我们的内部测试可以成功地GWT序列化服务器创建的Optional，但这不是我们的公共Guava版本第一次无法匹配我们的内部GWT行为。
从您提供的链接中，听起来您已经完成了我建议的前两件事：确保您的客户端和服务器端库都依赖于guava-gwt，并声明对{的依赖性您的GWT模块中的{1}}。
我目前的另一个想法是问你的DTO是什么样的。 GWT有时难以确定需要准备哪些类来进行序列化。真的，我怀疑这是问题所在：GWT显然有一些暗示它可能需要序列化com.google.common.base.Base，而且无论如何，这些问题通常只出现在Present字段中，这可能会让你更加根本困难。
你也可以确保你不会以某种方式传递不同版本的番石榴。如果它是一个真正的Maven传递依赖，那么我认为Maven会出错，但如果你的一个依赖关系将Guava类直接捆绑到它的jar中，那么Maven可能不会注意到。这似乎也不太可能，但我正在抓住稻草。
如果你能把一个我可以在本地运行的测试用例放在一起，我可以进一步调查。