Sybex 816, Chapter 11, pag. 596

[Ilenia Salvadori]

In Table 11.2, the parameters of writeObject() and readObject() seem to be inverted. writeObject() should take an ObjectOutputStream as parameter, while readObject() should take an ObjectInputStream.
Right?

[Campbell Ritchie]

Please supply more details of what the book says. The types you have given are the types the methods are called on, not their parameters. See ObjectOutputStream#writeObject(Object) and ObjectInputStream#readObject().
I can't find such an erratum here, so you may get recognition for finding a “new” error.

[Ilenia Salvadori]

So, in Table 11.2 at pag. 596 there is a list of the methods for serialization and deserialization. The table lists the return type, the method name, the method parameters and the description.
The two lines which correspond to the methods writeObject() and readObject() are the following:

Return Type	Method		Parameters	Description
void	writeObject()		ObjectInputStream	Serializes optionally using PutField
void	readObject()		ObjectOutputStream	Deserializes optionally using GetField

I think in the third column (Parameters) the two should be inverted, meaning writeObject() takes an ObjectOutputStream as parameter, while readObject() takes an ObjectInputStream.

[Campbell Ritchie]

Those would seem to be different methods from what I linked to. Which classes are those methods in? The readObject method I told you about earlier returns Object, not void. I think we need more information please.

[Ilenia Salvadori]

The methods I am referring to are not the ones from ObjectInputStream and ObjectOutputStream, but are the ones that you can optionally provide in a class that implements the Serializable interface, when you want to use ObjectInputStream.getField and ObjectOutputStream.putField respectively.

[Campbell Ritchie]

You can verify the method signatures in the Serializable documentation. There are fuller descriptions in several books, e.g. Thinking in Java by Bruce Eckel, and many cert exam books.

[Ilenia Salvadori]

Yes, which prove my point. In the documentation you find

Classes that require special handling during the serialization and deserialization process must implement special methods with these exact signatures:

private void writeObject(java.io.ObjectOutputStream out)
    throws IOException
private void readObject(java.io.ObjectInputStream in)
    throws IOException, ClassNotFoundException;

so, writeObject takes an ObjectOutputStream as parameter, and readObject takes an ObjectInputStream. Which is the opposite of what is written in tab 11.2 pag. 596 of the book.

[Jeanne Boyarsky]

Confirmed and added to the errata