The I/O Package - The Java Programming Language - page 815

When deserializing an HTTPInput object, ObjectInputStream first allocates
memory for the new object and then finds the first Serializable class
in the object's type hierarchyin this case URLInput . The stream invokes
the no-arg constructor of that class's superclass (the object's last non-
serializable class), which in this case is InputSource . If other state from
the superclass must be preserved, URLInput is responsible for serializing
that state and restoring it on deserialization. If your non-serializable su-
perclass has state, you will almost certainly need to customize the first
serializable class (see the next section). If the first serializable class dir-
ectly extends Object (as the earlier Name class did), customizing is easy
because Object has no state to preserve or restore.
Once the first serializable class has finished with its part of its super-
class's state, it will set its own state from the stream. Then ObjectIn-
putStream will walk down the type tree, deserializing the state for each
class using readObject . When ObjectInputStream reaches the bottom of the
type tree, the object has been completely deserialized.
As the stream is deserialized, other serialized objects will be found that
were referenced from the object currently being deserialized. These oth-
er objects are deserialized as they are encountered. Thus, if URLInput
had a reference to a HashMap , that hash map and its contents would be
deserialized before the HTTPInput part of the object was deserialized.
Before any of this can happen, the relevant classes must first be loaded.
This requires finding a class of the same name as the one written and
checking to see that it is the same class. You'll learn about versioning
issues shortly. Assuming it is the same class, the class must be loaded.