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