Why are readObject and writeObject private, and why would I write transient variables explicitly?

Question

I am reading the chapter on Serialization in Effective Java.

1. Who calls the readObject() and writeObject()? Why are these methods declared private ?

2. The below is a piece of code from the book

   // StringList with a reasonable custom serialized form
   public final class StringList implements Serializable {
       private transient int size = 0;
       private transient Entry head = null;
   
       //Other code
   
       private void writeObject(ObjectOutputStream s)
           throws IOException {
           s.defaultWriteObject();
           s.writeInt(size);
           // Write out all elements in the proper order.
           for (Entry e = head; e != null; e = e.next)
              s.writeObject(e.data);
           }
       }
   }
   

   Is there any specific reason the variable size is declared as transient and then in the writeObject method it is explicitly written? If it were not declared as transient, it would have been written anyway, right?

Answer 1

(1) The methods are not declared in any class or interface. A class, that implements the Serializable interface and requires special special handling during the serialization and deserialization process must implement those methods and the serializer/deserializer will try to reflect those methods.

This is one of the rather strange corners in Java where the API is actually defined in the javaDoc... But if the methods had been defined in an interface, then they had to be public (we can't implement an interface method an lock it by adding a private modifier).

Why private - the javaDoc does not give a hint. Maybe they are specified as private because no other class but the implementor is intended to use them. They are private by definition.

(2) The example simply shows how the special handling works. In this example, size is transient and will not be serialized. But now we introduce the special handler and this handler adds the value of size to the stream. The difference to the normal approach with non-transient fields could be the order of elements in the resulting stream (if it matters...).

The example could make sense, if the transient field was defined in a super class and a subclass wanted to serialize the value.