Externalizable -
To get complete control on class persistence as byte stream, java provides Externalization.
or you can also writes the data in the compress format it is not the marker interface
public void writeExternal(ObjectOutput out) throws IOException
public void readExternal(ObjectInput in) throws IOException
it gives you flexibility to write your own mechanism instead of using the java default serialization
public class User implements Externalizable {
private String name;
private int age;
User(){
}
User(String name , int age){
this.name = name;
this.age = age;
}
@Override
public void readExternal(ObjectInput in) throws IOException,
ClassNotFoundException {
name = (String) in.readObject();
age = in.readInt();
}
@Override
public void writeExternal(ObjectOutput out) throws IOException {
out.writeObject(name);
out.writeInt(age);
}
}
//Write code for writing object in the file and reading the object from the file.
What will happen when an externalizable class extends a non externalizable super class?
Then in this case, you need to persist the super class fields also in the sub class that implements Externalizable interface
and also mandatory no arg constructor if you define your constructor with arguments
Difference in serialization and Externalization?
1-serialization is a recursive process and goes till object class
you can stop it in Externalization it only goes to super class you extends
2-JVM create serialVersionUID based on object type in serialization. if you don't define expilcitly
what is serialVersionUID and for what it is use for??
private static final long serialVersionUID = 2641225946319834341L;
it is an id which is associated with the object when it is serialized usually a hascode of the object.
it is used for the version control of the object. if you modify the class after serialized. then it will not be able to recover at the time of de-serialization because the serialVersionUID is different for the new class. throws InvalidClassException.
How Serialization can put constraints on your ability to change class is SerialVersionUID.
If you don't explicitly declare SerialVersionUID then JVM generates its based upon structure of class which depends upon interfaces a class implements and several other factors which is subject to change
To get complete control on class persistence as byte stream, java provides Externalization.
or you can also writes the data in the compress format it is not the marker interface
public void writeExternal(ObjectOutput out) throws IOException
public void readExternal(ObjectInput in) throws IOException
it gives you flexibility to write your own mechanism instead of using the java default serialization
public class User implements Externalizable {
private String name;
private int age;
User(){
}
User(String name , int age){
this.name = name;
this.age = age;
}
@Override
public void readExternal(ObjectInput in) throws IOException,
ClassNotFoundException {
name = (String) in.readObject();
age = in.readInt();
}
@Override
public void writeExternal(ObjectOutput out) throws IOException {
out.writeObject(name);
out.writeInt(age);
}
}
//Write code for writing object in the file and reading the object from the file.
What will happen when an externalizable class extends a non externalizable super class?
Then in this case, you need to persist the super class fields also in the sub class that implements Externalizable interface
and also mandatory no arg constructor if you define your constructor with arguments
Difference in serialization and Externalization?
1-serialization is a recursive process and goes till object class
you can stop it in Externalization it only goes to super class you extends
2-JVM create serialVersionUID based on object type in serialization. if you don't define expilcitly
what is serialVersionUID and for what it is use for??
private static final long serialVersionUID = 2641225946319834341L;
it is an id which is associated with the object when it is serialized usually a hascode of the object.
it is used for the version control of the object. if you modify the class after serialized. then it will not be able to recover at the time of de-serialization because the serialVersionUID is different for the new class. throws InvalidClassException.
How Serialization can put constraints on your ability to change class is SerialVersionUID.
If you don't explicitly declare SerialVersionUID then JVM generates its based upon structure of class which depends upon interfaces a class implements and several other factors which is subject to change
Comments
Post a Comment