Serialization with primitive long

[daveh]

I have a class which I am able to serialize ok - it has a load of
private String objects in it and a getter and a setter for each of
them.

As soon as I add a primitive long in to the class and give it getter
and setters like this :

private long count = 0;

public long getCount() {
return count;
}

public void setCount(long count) {
this.count = count;
}

I can no longer serialize it. I get

java.lang.RuntimeException: JavaScript method
'@com.dave.client.MyService_TypeSerializer::deserializeImpl(Lcom/google/gwt/user/client/rpc/SerializationStreamReader;Lcom/google/gwt/user/client/rpc/SerializationStreamObjectDecoder;Ljava/lang/String;)'
threw an exception
at
com.google.gwt.dev.shell.ie.ModuleSpaceIE6.invokeNative(ModuleSpaceIE6.java:365)
at
com.google.gwt.dev.shell.ie.ModuleSpaceIE6.invokeNativeObject(ModuleSpaceIE6.java:204)
at
com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:103)
at com.dave.client.MyService_TypeSerializer.deserializeImpl(transient
source for com.dave.client.MyService_TypeSerializer:48)
at com.dave.client.MyService_TypeSerializer.deserialize(transient
source for com.dave.client.MyService_TypeSerializer:44)
at
com.google.gwt.user.client.rpc.ClientSerializationStream.readObject(ClientSerializationStream.java:348)
at com.dave.client.MyService_Proxy$1.onCompletionImpl(transient source
for com.dave.client.MyService_Proxy:57)
at com.dave.client.MyService_Proxy$1.onCompletionAndCatch(transient
source for com.dave.client.MyService_Proxy:44)
at com.dave.client.MyService_Proxy$1.onCompletion(transient source for
com.dave.client.MyService_Proxy:38)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
com.google.gwt.dev.shell.InstanceJavaDispatch.callMethod(InstanceJavaDispatch.java:40)
at
com.google.gwt.dev.shell.ie.IDispatchProxy.invoke(IDispatchProxy.java:117)
at
com.google.gwt.dev.shell.ie.IDispatchImpl.Invoke(IDispatchImpl.java:199)
at
com.google.gwt.dev.shell.ie.IDispatchImpl.method6(IDispatchImpl.java:108)
at
org.eclipse.swt.internal.ole.win32.COMObject.callback6(COMObject.java:117)
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1656)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2711)
at com.google.gwt.dev.GWTShell.pumpEventLoop(GWTShell.java:491)
at com.google.gwt.dev.GWTShell.run(GWTShell.java:459)
at com.google.gwt.dev.GWTShell.main(GWTShell.java:208)

.... lots more of the same ......

If I've understood the notes about serialization correctly, primitive
types should be serialized OK.

What am I missing?

Dave

[daveh]

It works if I use an int raher than a long.

It even works if I declare the following :

private int count = 0;

public long getCount() {
return count;
}

public void setCount(long count) {
this.count = (int)count;
}

But to get this to work after a run where the count is declared as a
long, I need to restart the development shell.

Dave

[Charlie Dobbie]

Hi Dave,

Might it be related to this:

http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.JavaToJavaScriptCompiler.LanguageSupport.html

"However, there is no 64-bit integral type in JavaScript, so variables
of type long are mapped onto JavaScript double-precision floating
point values. To ensure maximum consistency between hosted mode and
web mode, we recommend that you use int variables."

Charlie.

[daveh]

Thanks Charlie - I remember reading that before and thinking "I bet
that'll catch a few people out..." :) Doh!

[Scott Blum]

> But to get this to work after a run where the count is declared as a
> long, I need to restart the development shell.

Dave, that might actually be the main cause of the problem. Your
server side code is running as compiled class files and (unless your
IDE is very good) won't be able to get "fresh" versions of the class
while running. Your client side code is compiled fresh every time so
reloading should instantly reflect any source changes. So the error
was likely caused by your server and client being out of sync rather
than that you were using the long type. In general, it's probably best
to restart the shell when you've made server side (or server-affecting
in this case) changes. But as Charlie points out, using longs is
discouraged.

Scott