Date が GWT 2.4.0 によってシリアル化される方法に問題がありました。最も簡単な解決策は、元の実装をオーバーロードする Date_CustomFieldSerializer を作成することです。
しかし、アプリケーションの起動方法によっては、異なる結果が得られます。幸いなことに、デプロイされたバージョンは問題なく動作するようです。一方、Eclipse からデバッグ セッションを開始すると、次のメッセージが表示されます。
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)
サーバー側とクライアント側の両方をデバッグしましたが、サーバーはシリアライザーを使用しており、「型シグネチャ」でシリアライザーを検索しているときにクライアント側が失敗します。java.util.Date/1659716317
奇妙なことに、クライアントには のシリアライザーを含むマップがありますjava.util.Date/965047388
。
GWT はこれらの型シグネチャをどのように作成し、GWT デバッガーを使用しているときにどのように異なるのでしょうか?
- 編集 -
数値がどのように生成されるかがわかりました。GWT は、階層内のクラス名 (場合によってはメソッドも) の CRC32 ハッシュを計算します。
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)
CompilingClassLoader と実行時に生成されたクラスの間のどこかにあるため、GWT がクライアント側のハッシュを計算してシリアライザーを認識しない理由を確認する場所を見つけることができません。