Implementing Serializable without providing writeObject / readObject method

Question

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?

Answer 1

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,

Answer 2

1)Will the default methods defaultWriteObject/defaultReadObject do the serialization or not? -NO,

defaultReadObject() invokes the default deserialization mechanism, and is used when you define the readObject() method on your Serializable class. In other words, when you have custom deserialization logic, you can still get back to the default serialization, which will deserialize your non-static, non-transient fields. For example:

public class TestClass implements Serializable {
    private String f2;
    private int f1;
    private transient String f3; 
    private void readObject(java.io.ObjectInputStream stream)
         throws IOException, ClassNotFoundException {
         stream.defaultReadObject(); //fills f1 and f2;
         fld3 = Configuration.getFooConfigValue();
    }
}

On the other hand, readObject() is used when you create the ObjectInputStream, externally from the deserialized object, and want to read an object that was previously serialized:

ObojectInputStream stream = new ObjectInputStream(aStreamWithASerializedObject);
Object foo = (Foo) stream.readObject();

The java.io.ObjectOutputStream.defaultWriteObject() method writes the non-static and non-transient fields of the current class to this stream. This may only be called from the writeObject method of the class being serialized This method allows to take complete control over what will be sent over the wire. In most cases, you will just call out.defaultWriteObject() to benefit from the default serialization process.

2)Is only marking the class with implements Serializable enough to serialize a class? Yes,

Any object whose class implements the java.io.Serializable interface can be made persistent with only a few lines of code. No extra methods need to be added to implement the interface, however - the purpose of the interface is to identify at run-time which classes can be safely serialized, and which cannot. You only need to add the implements keyword to your class declaration, to identify your classes as serializable.

Now, once a class is serializable, we can write the object to any OutputStream, such as to disk or a socket connection. To achieve this, we must first create an instance of java.io.ObjectOutputStream, and pass the constructor an existing OutputStream instance.

/ Write to disk with FileOutputStream
FileOutputStream f_out = new 
    FileOutputStream("myobject.data");

// Write object with ObjectOutputStream
ObjectOutputStream obj_out = new
    ObjectOutputStream (f_out);



 // Write object out to disk
    obj_out.writeObject ( myObject );

3)If yes, then what is getting serialized and where is the state of object getting persisted? All the non-transient non-static member variables of the class and all its base classes that implement Serializable will get persisted in some media/file.object's state to a persistence store and also rebuilding the object from the saved information when needed in the future.

Answer 3

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.