Uses of readObject/writeObject in Serialization

Question

I was going through this article to understand more about Java Serialization process. When it comes to uses of readObject/writeObject I could see two use cases:

Answer 1

You can implement you own readObject/writeObject for performance reasons, or backward compatibility reasons, or because a field you want to serialize is not Serializable.

For good examples of readObject/writeObject I would look in the source which comes with the JDK. Or I would try http://www.google.co.uk/search?q=readObject+writeObject+examples

Answer 2

Custom readObject methods are also useful when you need to initialize transient (non-serialized) fields after the object has been deserialized.

---

BTW, check out Effective Java, Chapter 11 (I'm not sure what the chapter/item number is in the 2nd ed.). It's an excellent read on serialization.

Answer 3

public class Employee implements Serializable {

    private static final long serialVersionUID = 1L;

    private int empno;
    private String ename;
    private String job;

    // setter & getter

    @Override
    public String toString() {
        return "Employee [empno=" + empno + ", ename=" + ename + ", job=" + job
                + "]";
    }

    private void writeObject(ObjectOutputStream out) throws IOException {

        // default serialization
        // out.defaultWriteObject();

        // custom serialization
        out.writeInt(empno);
        out.writeUTF(ename);
        // out.writeUTF(job); //job will not serialize
    }

    private void readObject(ObjectInputStream in) throws IOException,
            ClassNotFoundException {

        // default deSerialization
        // in.defaultReadObject();

        // custom deSerialization
        empno = in.readInt();
        ename = in.readUTF();
        // this.job = in.readUTF();
    }

}

Answer 4

I thing decrypting can better be done by using an ObjectOutputStream based on an CipherOutputsStream.

The most important use of writeObject/readObject is if you want to keep Serialization stable over multiple code revisions. Your internal representation (member variables) may change but serialization has to be stable as there are old system you communicate with (e.g. by reading old data from files).

But I prefer the Externalizable interface for these cases as it is easier to use (no implicit calls and methods which only the jvm knows about).

Answer 5

There could be several reasons for using custom serialization:

1. Performance.
2. Interfacing with external systems. (Beyond-your-reach or even simply non-Java systems.)
3. Needing a human-readable format.
4. Support for older versions of serialized classes.

To name just a few, but I'm sure there are many more.