超级类和子类的序列化

Question

My doubt is using Scenario 1 it is possible to achieve serialization . If I extend one abstract class which is serializable by many sub classes means , is this possible to achieve ?. As I tried with Scenario 2.

Serializable will be applicable for all beans or not,Please help me.

my doubt scenario 1 and scenario 2 will be same or different.

//method to send message ::: sendMsgs(SerializableObject)

Scenario 1:

public class EmailMaster implements Serializable 
{
// setters and getters
}

Scenario 2:

public abstract class MessageBean implements Serializable 
{ 
}

//whether EmailMaster and EmailEvent  will become serializable ?

public class EmailMaster extends MessageBean 
{
// setters and getters



public class EmailEvent extends MessageBean 
{
// setters and getters
}

Answer 1

This should be Serialilzable . When you extend MessageBean , all extending classes of MessageBean be default inherit the Serializable interface from MessageBean abstract class.

I would advice to have unique serialVersionUID assigned in each extending(sub) classes.

EDIT: From Searialization perspective, scenario1 and sceanrio2 are not different but theoretically they are different as you are having an additional abstract class in sceario2 , which can have more methods/attributes, which will also get available to the EmailMaster class.

In both the scenarios: sendMsgs(SerializableObject) should work. Make a decision between sceanrio1 and scenario2 based on the need of abstract class in between. If you don't need the abstract class for any other purpose, go with scenario1.

Answer 2

Serializable is inherited by all the subclasses of the abstract class as for any other interface:

If A implements Serializable , whatever class extends A will be Serializable

So both Scenarios will work but in any case a concrete Serializable class must have a no-args constructor . See the following Serializable Javadoc :

Serializability of a class is enabled by the class implementing the java.io.Serializable interface. Classes that do not implement this interface will not have any of their state serialized or deserialized. All subtypes of a serializable class are themselves serializable. The serialization interface has no methods or fields and serves only to identify the semantics of being serializable.

To allow subtypes of non-serializable classes to be serialized, the subtype may assume responsibility for saving and restoring the state of the supertype's public, protected, and (if accessible) package fields. The subtype may assume this responsibility only if the class it extends has an accessible no-arg constructor to initialize the class's state . It is an error to declare a class Serializable if this is not the case. The error will be detected at runtime.

Moreover, regarding the Serial Version ID of the object:

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.

Answer 3

Try

Serializable emailMaster = new EmailMaster();

If it works then EmailMaster is-a Serializable . AFAIK, that definitely should work.