I'll be very much obliged if one of the authors of the book could answer the question.
Besides transient instance variables, static class members will also be ignored during the serialization and deserialization process. This should follow logically, as static class variables do not belong to one particular instance. Page 427
This serialVersionUID is stored with the serialized object and assists during the deserialization process. Page 428
The serialVersionUID is a static variable and is it not being ignored in the serialization process and the deserialization process here? what did you have in mind when you said the 2nd sentence in the above quote?
Furthermore, any static variables or default initializations are ignored. Page 431
This quote on Page 431 is under the title of "Understanding Object Creation." Under that title, the first sentence starts with "For the exam, you need be aware of how a deserialized object is created." So, I'm really confused whether you mean the quote on Page 431 for dealing with a serialization process or a deserialization process.
Stephan van Hulst wrote:In general, all static class members will be ignored. serialVersionUID is a little bit more magic, it's specially used for the serialization mechanism, so obviously that one won't be ignored.
In short, serialVersionUID is the exception, and will not be ignored, but is also not serialized in the same way as regular non-static non-transient fields.
There is nothing special about serialVersionUID. It's just a variable name. You said serialVersionUID is an exception. Why is that an exception? Is that because it's declared as a static final variable? If it's an exception, I would be very grateful if you could elaborate on the role a final static variable plays in the processes of serialization and deserialization.
This variable is used by the Java serialization/ de-serialization process to ensure that the version of a Java class used to de-serialize an object is the same as the vesrion that was used to serialize it.
Imagine you used version1 of a Java application and serialized an object of one of its class, say, Transaction. It is usual for requirements to change and applications to upgrade. After some time, imagine, you use version2 of this application. What happens if class Transaction is modified in the second version? Should the serialized object of class Transaction from version1 be allowed to be de-serialized by class's version2 (which might include different class structure)?
Java prevents this by using static variable serialVersionUID.
The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException. A serializable class can declare its own serialVersionUID explicitly by declaring a field named "serialVersionUID" that must be static, final, and of type long:
ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;
If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification. However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class--serialVersionUID fields are not useful as inherited members. Array classes cannot declare an explicit serialVersionUID, so they always have the default computed value, but the requirement for matching serialVersionUID values is waived for array classes.