I had a problem with the way Date was serialized by GWT 2.4.0 and the easiest solution seemed to be to write a Date_CustomFieldSerializer - overloading the original implementation.
But depending on how i start the application i get different results. Gladly the deployed version seems to work without any trouble. Starting a debugging session from Eclipse on the other hand leads to this message:
com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException: The response could not be deserialized
at com.google.gwt.user.client.rpc.impl.RequestCallbackAdapter.onResponseReceived(RequestCallbackAdapter.java:221)
at com.google.gwt.http.client.Request.fireOnResponseReceived(Request.java:287)
at com.google.gwt.http.client.RequestBuilder$1.onReadyStateChange(RequestBuilder.java:395)
...
Caused by: com.google.gwt.user.client.rpc.SerializationException: java.util.Date/1659716317
at com.google.gwt.user.client.rpc.impl.SerializerBase.getTypeHandler(SerializerBase.java:153)
I debugged both the server and the client side and the server is using my serializer and the client side fails when it's looking up the serializer by its "type signature": java.util.Date/1659716317
Oddly the client has a map containing a serializer for java.util.Date/965047388
.
How does GWT create these type signatures and how can they be different when i am using the GWT debugger?
-- edit --
I now know how the numbers are generated. GWT calculates a CRC32 hash of the class names in the hierachy (and sometimes the methods as well).
java.util.Date
com.google.gwt.user.client.rpc.core.java.util.Date_CustomFieldSerializer
java.lang.Object
--> 1659716317 (server side)
java.util.Date
java.lang.Object
--> 965047388 (client side)
I just can't find the spot when the GWT calculates the hashes for the client side to see why it doesn't know the serializer, because it's somewhere between a CompilingClassLoader and runtime generated classes.