sencillo - polimorfismo java

Serialización y herencia de objetos Java

Question

Digamos que tienes estas dos clases, Foo and Bar donde Bar extiende Foo e implementa Serializable

class Foo {
public String name;
public Foo() {
this.name = "Default";
}
public Foo(String name) {
this.name = name;
}
}
class Bar extends Foo implements java.io.Serializable {
public int id;
public Bar(String name, int id) {
super(name);
this.id = id;
}
}

Tenga en cuenta que Foo no implementa Serializable . Entonces, ¿qué sucede cuando el bar está serializado?

 public static void main(String[] args) throws Exception {
FileOutputStream fStream=new FileOutputStream("objects.dat");
ObjectOutputStream oStream=new ObjectOutputStream(fStream);
Bar bar=new Bar("myName",21);
oStream.writeObject(bar);
FileInputStream ifstream = new FileInputStream("objects.dat");
ObjectInputStream istream = new ObjectInputStream(ifstream);
Bar bar1 = (Bar) istream.readObject();
System.out.println(bar1.name + " " + bar1.id);
}

imprime "Default 21". La pregunta es, ¿por qué se llama al constructor predeterminado cuando la clase no está serializada?

Answer 1

En realidad, cuando vuelva a leer el objeto de la clase padre, ya que no se serializará. Por lo tanto, para las cosas que no se serializarán, JVM pasará por el mismo proceso que cuando creamos el nuevo objeto utilizando una palabra clave nueva.

Answer 2

Es posible que el defaultWriteObject solo pueda escribir los campos no estáticos y no transitorios de la clase actual . Una vez que la superclase no implementa la interfaz Serializable, los campos de la superclase no se pueden serializar en la secuencia.

Answer 3

Serializable es solo una "interfaz de marcador" para una clase determinada.

Pero esa clase debe cumplir con ciertas reglas:

http://docs.oracle.com/javase/1.5.0/docs/api/java/io/Serializable.html

Para permitir la serialización de subtipos de clases no serializables, el subtipo puede asumir la responsabilidad de guardar y restaurar el estado de los campos del paquete público, protegido y (si es accesible) del supertipo. El subtipo puede asumir esta responsabilidad solo si la clase que se extiende tiene un constructor no arg accesible para inicializar el estado de la clase. Es un error declarar una clase Serializable si este no es el caso.

responder a la pregunta de @Sleiman Jneidi en un comentario, en la documentación del oráculo mencionada anteriormente, se menciona claramente

Durante la deserialización, los campos de las clases no serializables se inicializarán utilizando el constructor público o protegido no-arg de la clase. Un constructor no arg debe ser accesible para la subclase que es serializable. Los campos de subclases serializables se restaurarán desde la secuencia.

Por lo tanto, el constructor no-arg predeterminado de la clase a la que llamó Foo, dio como resultado la inicialización.