Android Hashtable Serialization

Question

I am having a weird issue with serialization of a Hashtable. I have made a Server, Client app. Where server(PC/MAC) is serializing a Hashtable and sending it to Client(Android) through UDP. The data is sent/read correctly but I get a bunch of these messages below on LogCat.

04-12 11:19:43.059: DEBUG/dalvikvm(407): GetFieldID: unable to find field Ljava/util/Hashtable;.loadFactor:F

Occasionally, I would see these

04-12 11:21:19.150: DEBUG/dalvikvm(407): GC freed 10814 objects / 447184 bytes in 97ms

The app would run for 2-3 mins and then crash. Interestingly enough I do not see the Loadfactor errors on SDK 1.5. But I do see the GC Free xxxx objects, quiet often.

After debugging I have found that the issue is with de-serialization and the error/warning are coming from following code

Code:

ByteArrayInputStream bis = new ByteArrayInputStream(bytes);           
ObjectInputStream ois = new ObjectInputStream(bis);             
object = ois.readObject(); 

at Code:

object = ois.readObject();

on the client. My server is serializing code is the following.

Code:

ByteArrayOutputStream bos = new ByteArrayOutputStream(); 
ObjectOutputStream oos = new ObjectOutputStream(bos);               
oos.writeObject(obj);       

Any idea what is going on?

Thanks for the Help!

Answer 1

Do not use serialization between architectures. There is no guarantee that a serialized Dalvik VM object tree will be in a format that is compatible with a JavaSE/JavaEE environment. Please use XML, JSON, Protocol Buffers, Thrift, etc. for transferring structured data between architectures.

Answer 2

Far too late, but for anyone else who comes across this:

Noting what commonsware said above (Don't say you weren't warned):

I got over this by using the trove libraries and using long object maps. I realise that if dalvik or Java changes the serialization I am stuffed, but serialization is so much easier than the alternatives and that error message (whilst benign) does mean a lot of unnecessary allocations and overhead. On top of this I use proguard to reduce the library down to the 45K (out of ~1M) that I need. I would also suggest that you keep a copy of the trove source code in case they change their serialization, and also note that I needed 3.0.0 rc1 to get it to work (not sure the serialid's necessarily match between versions).