Reputation: 69
What if a class is implementing serializable interface, but there's no writeObject/readObject
method implementation anywhere in the codebase?
Will the default methods defaultWriteObject/defaultReadObject
do the serialization or not?
Is only marking the class with implements Serializable
enough to serialize a class?
If yes, then what is getting serialized and where is the state of object getting persisted?
Upvotes: 6
Views: 2535
Reputation: 311028
What if a class is implementing serializable interface, but there's no
writeObject/readObject
method implementation anywhere in the codebase?
It will be subject to default serialization: see below.
Will the default methods
defaultWriteObject/defaultReadObject
do the serialization or not?
No, because they won't be invoked unless you invoke them.
Is only marking the class with
implements Serializable
enough to serialize a class?
Yes, if you're content with default serialization: see below.
If yes, then what is getting serialized
All the non-transient non-static member variables of the class and all its base classes that implement Serializable,
and nothing else.
and where is the state of object getting persisted?
Into the stream. This part of your question doesn't seem to make sense,
Upvotes: 4
Reputation: 310
https://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html
this is also a great doc to refer to understand the point you are asking for a snippet of this doc which may help you understanding it more.
The writeObject method is responsible for writing the state of the object for its particular class so that the corresponding readObject method can restore it. The default mechanism for saving the Object's fields can be invoked by calling out.defaultWriteObject. The method does not need to concern itself with the state belonging to its superclasses or subclasses. State is saved by writing the individual fields to the ObjectOutputStream using the writeObject method or by using the methods for primitive data types supported by DataOutput.
The readObject method is responsible for reading from the stream and restoring the classes fields. It may call in.defaultReadObject to invoke the default mechanism for restoring the object's non-static and non-transient fields. The defaultReadObject method uses information in the stream to assign the fields of the object saved in the stream with the correspondingly named fields in the current object. This handles the case when the class has evolved to add new fields. The method does not need to concern itself with the state belonging to its superclasses or subclasses. State is saved by writing the individual fields to the ObjectOutputStream using the writeObject method or by using the methods for primitive data types supported by DataOutput.
The readObjectNoData method is responsible for initializing the state of the object for its particular class in the event that the serialization stream does not list the given class as a superclass of the object being deserialized. This may occur in cases where the receiving party uses a different version of the deserialized instance's class than the sending party, and the receiver's version extends classes that are not extended by the sender's version. This may also occur if the serialization stream has been tampered; hence, readObjectNoData is useful for initializing deserialized objects properly despite a "hostile" or incomplete source stream.
Upvotes: 0