This is one of the big differences between Externalizable and Serializable from the javadocs for Externalizable.java.
When an Externalizable object is reconstructed, an instance is created using the public no-arg constructor, then the readExternal method called. Serializable objects are restored by reading them from an ObjectInputStream.
The readObject and writeObject methods are specified in the javadocs for Serializable.java.
Consider a situation where you have as an instance variable in your Serializable class a reference to a class which is not Serializable.
If you tried to serialize your object, you will get an exception.
However, you can mark the instance variable as transient and use the writeObject and readObject to write the state of that object to the stream and read it back in.
posted 13 years ago
Thanks Keith for your response.
But I still have a doubt. Kindly help me understand the logic behind serialization. readObject/writeObject methods are defined in ObjectInputStream and ObjectOutputStream. Right! Now why do not we override these methods by subclassing ObjectInputStream. Why do we define them in a class implementing serializable interface. How does JVM come to know when to call these methods or to perfom default serialization process.
My main issue is why we have to define these methods when nothing of that sort is defined in Serializable Interface.
Now why do not we override these methods by subclassing ObjectInputStream.
Because then the custom methids would be used for all objects being serialized, which is not what we want. We'd also need to take care that the JVM doing the deserialization uses the custom Object[In|Out]putStream as well.
Why do we define them in a class implementing serializable interface. How does JVM come to know when to call these methods or to perfom default serialization process.
The glib answer is: because the javadocs say so, and the JVM is written that way. Marker interfaces cause special things to happen, and all code dealing with objects with those interfaces need to know what to do. If your code were to introduce some marker interface, it would need to know internally how to handle objects implementing those interfaces. Same with the JVM and Serializable. That's one of the reasons marker interfaces fell out of favor.
readObject(ObjectInputStream)/writeObject(ObjectOutputStream) is defined in a class implementing Serializable interface to customize the serialization process. Note what is the logic behind implementing this. We need to do this when we want to save the state of a transient variable of the class. Now you are saying we could have defined these methods in a subclass of ObjectInputStream/ObjectOutputStream but had we done that how you will be able to implement logic to save the state of your transient variable. When we implement readObject(ObjectInputStream)/writeObject(ObjectOutputStream) methods in the class we get the oppurtunity to save / retrieve the transient variable values and then the default readObject()/writeObject() methods is called by JVM when these methods execute.
JVM just check for the Serializable Marker interface. It suggests JVM that you can serialize the object.
Hope this helps.
Life just hasn't been the same since the volcano erupted and now the air is full of tiny ads.