How to code with respect to Serialization
When I try to deSerialize a class I get NullPointerException.
When another class tries to call
public ShapeMultiPath getShapeMultiPath() it returns null.
The method exists in a class that looks like
package data;
import java.io.Serializable;
import com.graphbuilder.curve.ControlPath;
import com.graphbuilder.curve.ShapeMultiPath;
publicclass PathPairimplements Serializable{
ControlPath cp;
transient ShapeMultiPath multi;
public PathPair(ControlPath cp){
this.cp = cp;
multi =new ShapeMultiPath();
}
public ControlPath getControlPath(){
return cp;
}
public ShapeMultiPath getShapeMultiPath(){
return multi;
}
}
When you recreate objects with readObject(), what happens? Does it call the constructor or does it create the object in some magic way?
Anyhow, how do I make the variable multi to be something when recreating the object?
(I did also try;transient ShapeMultiPath multi = new ShapeMultiPath(); instead of creating it in the constructor but that didn磘 help either.
[1814 byte] By [
sandsatera] at [2007-10-3 4:32:25]
> When you recreate objects with readObject(), what
> happens? Does it call the constructor or does it
> create the object in some magic way?
Neither. It simply loads the attribute values from the file. That's what serialization is all about.
> Anyhow, how do I make the variable multi to be
> something when recreating the object?
I guess Externalization might help - never used it. You could implement the readExternal method to set multi to some value I guess. Or you could simply post-process the object after loading it.
The following sample code may clarify a few points for you. I have modifed a couple of methods from some of my code so I hope it works here but it should do.
Also in the class to be serialised, add the line:
private static final long serialVersionUID = 1234L;// unique number here
so that the class is upgradeable without exception errors in the future. Otherwise, a change to the class will render it incompatable with a currently save file. You will obviously have to make allowances for the fact that the 'old' file may not have the current methods for the new code.
package data;
import java.io.Serializable;
import com.graphbuilder.curve.ControlPath;
import com.graphbuilder.curve.ShapeMultiPath;
public class PathPair implements Serializable{
private static final long serialVersionUID = 1234;// unique number here
ControlPath cp;
//transient ShapeMultiPath multi;
public PathPair(ControlPath cp){
this.cp = cp;
multi = new ShapeMultiPath();
}
public ControlPath getControlPath(){
return cp;
}
public ShapeMultiPath getShapeMultiPath(){
return multi;
}
}
private PathPair readFile() {
try {
ObjectInputStream in = new ObjectInputStream(new FileInputStream(new File("pair.ini")));
PathPair p = (PathPair) in.readObject();
in.close();
return p;
} catch(ClassNotFoundException cnfe) {
return new PathPair();
} catch (FileNotFoundException fnfe){
return new PathPair();
} catch (IOException ioe) {
return new PathPair();
}
}
public void saveFile(PathPair p) {
try {
ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream(new File("pair.ini")));
out.writeObject(p);
out.close();
} catch (FileNotFoundException fnfe){
//error message
} catch (InvalidClassException ice) {
//error message
} catch(IOException ioe) {
//error message
}
}
// within program
PathPair p = readFile();
// use p as per normal...
saveFile(p);
> You will obviously have to make allowances
> for the fact that the 'old' file may not have the
> current methods for the new code.
This is meaningless. The 'old' file doesn't have any methods at all, and it doesn't need them. It is just data.
What you do have to look out for is that the new class may be serialization-incompatible with the old data, in which case you have to take some evasive action - see the Versioning section in the Serialization specification.
ejpa at 2007-7-14 22:35:56 >
