bug in BinaryDeserializer?

Matthias Radestock <[email protected]>
Newsgroups gmane.comp.java.sisc.devel
Organization LShift Ltd
Message-ID <[email protected]>
I encountered the following problem:
* start SISC
* (import generic procedures)
* call (generic-java-procedure 'value-of)
==> NPE

I tracked this down to a deserialization problem. The NPE is caused in 
the hashCode method when we deserialize the *CLASSES* lookup table from 
the generic-procedures module. The key it is failing on is meant to be 
the java interface java.io.Serializable. This is a JavaObject and the 
reason hashCode is failing is that instead of the class the JavaObject 
contains null.

Adding some tracing to the (de)serialization reveals that the hashtable 
and contained JavaObjects get serialized correctly. However on hashtable 
deserialization the key object returned from the serializer is a
a non-initialized JavaObject. This happens because the JavaObject in 
question is not shared, i.e. it's of serialization type 0. 
BinaryDeserializer.readExpression in that case doesn't read the object 
immediately and instead just queues a read job.

Normally this doesn't make any difference, because the object content 
does get deserialized eventually and deserialization methods generally 
do not look at the content of objects. However, the latter is not true 
in case of hashtables since inserting the hashtable entries requires 
access to the contents of the key.

Is this a bug in the (de)serialization code or is this behaviour expected?


Matthias.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.