java.io.NotActiveException: not in call to writeObject
at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source)
at java.io.ObjectOutputStream.writeExternalData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
Javadoc for defaultWriteObject says: This may only be called from the writeObject method of the class
being serialized. It will throw the NotActiveException if it is called otherwise.
May be, what i am doing is Illegal or may never be required but wanted to know the reason and whats going on behind the scene..
Also,This is my first post and hence don't know enough rules of forum, not sure should i post it here or somewhere else
Welcome to JavaRanch! Yes, your question is quite appropriate for this forum.
I haven't actually hit a NotActiveException before, but I think the cause is that you explicitly call writeObject() and defaultWriteObject() from your code. Usually when you want a class to be Serializable, you just implement the Serializable interface and let the Java VM worry about the details. Serializable is a marker interface, which means it has no methods to implement. It just "marks" a class, telling the JVM that the class designer says that it's OK for this class to be converted to a serialized form.
Now the writeObject(), readObject() methods exists for the user to take some control over the serialization process. The only time I've ever used one was when I used the readObject() method to fix up objects serialized from a previous version of the class when I deserialized them. So, for example, if I had added a field to the class, I could use readObject() to set a value to that field when I deserialized an object that didn't have a value for it.
Externalizable extends Serializable, and lets the class author take complete control over the external representation of the serialized object. It forces you to implement the readExternal() and writeExternal() methods to accomplish this. If I understand it correctly, the JVM will still build the object tree when you decide to serialize something, but you decide how that tree will be translated to a serial form. I can see that being useful if you wanted to encrypt fields on serialization and decrypt them on deserialization.
Anyway, that got a bit long, but the basic idea is there's no reason to directly call the readObject() and writeObject() methods. If you include them in your class, you can just let the JVM decide when they're called. Most of the time you don't need to include them at all.
I hope you'll stick around the Ranch for awhile now that you've found us. Maybe even answer a few questions yourself!
posted 9 years ago
Thanks Greg for taking time out to reply.
Will definetly try to contribute more in this forum.
Nothing? Or something? Like this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop