Serializable interface
Have a look at the following programming snipet
import java.io.*;
class SuperNotSerial{
publicstaticvoid main(String [] args)
{
Dog d =new Dog(35,"Fido");
Animal a =new Animal();
System.out.println("before: " + d.name +" "+ d.weight);
try{< TRY BLOCK 1
FileOutputStream fs =new FileOutputStream("testSer.ser");
ObjectOutputStream os =new ObjectOutputStream(fs);
os.writeObject(d);
os.writeObject(a);< LINE X
os.flush();
os.close();
}catch (Exception e){ e.printStackTrace();}
/*try {< TRY BLOCK 2
FileOutputStream fs = new FileOutputStream("testSer.ser",true);
ObjectOutputStream os = new ObjectOutputStream(fs);
os.writeObject(a);
os.flush();
os.close();
} catch (Exception e) { e.printStackTrace(); }*/
try{< TRY BLOCK 3
FileInputStream fis =new FileInputStream("testSer.ser");
ObjectInputStream ois =new ObjectInputStream(fis);
Dog d2 = (Dog) ois.readObject();
Animal a1 = (Animal) ois.readObject();
System.out.println("Read: " + d2.name +" "+ d2.weight); System.out.println("Read: " + a1.weight);
ois.close();
}catch (Exception e){ e.printStackTrace();}
}
}
class Dogextends Animalimplements Serializable{
String name;
Dog(int w, String n){
weight = w;
name = n;
}
}
class Animalimplements Serializable{
int weight = 42;
}
I have 2 scenarious:
1. If i compile this code it is working fine. The output as follows. (Note:TRY BLOCK 2 is commented out)
before: Fido 35
Read: Fido 35
Read: 42
2. If i commented outLINE X inTRY BLOCK 1 and uncomment theTRY BLOCK 2, It is giving following out put:
before: Fido 35
java.io.StreamCorruptedException
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1326)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
at SuperNotSerial.main(SuperNotSerial.java:31)
Please explain.
Thanks,
Mohan
because you are trying to read an Animal object in try block 3 which would not be present in the file if you commented out that line.
Hi
I dont think so i have confused you. any how here is my detaioled explanation of my two scenarious.
Scenario 1:
step 1: open a new file
step 2: write object Dog to the file.
step 3: write object Animal to the file.
step 4: close file
step 5: open a file in read more.
step 6: read object Dog
step 7: read object Animal
It is printing what i am expected.
Scenario 2:
step 1: open a new file
step 2: write object Dog to the file.
step 3: close file
step 4: open file in append mode.
step 3: write object Animal to the file.
step 4: close file
step 5: open a file in read more.
step 6: read object Dog
step 7: read object Animal
Now it is not printing. It is throwing
java.io.StreamCorruptedException
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1341)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:354)
at SuperNotSerial.main(SuperNotSerial.java:33)
Why? Am i doing anythink wrong. If so please pointed out.
Regard,
Mohan
Some modifications in my scenario's:
Please read my scenario's as follows:
Scenario 1:
step 1: open a new file
step 2: write object Dog to the file.
step 3: write object Animal to the file.
step 4: close file
step 5: open a file in read more.
step 6: read object Dog
step 7: read object Animal
step 8: close file
Scenario 2:
step 1: open a new file
step 2: write object Dog to the file.
step 3: close file
step 4: open file in append mode.
step 5: write object Animal to the file.
step 6: close file
step 7: open a file in read more.
step 8: read object Dog
step 9: read object Animal
step 10: close file
> Scenario 2:
>step 1: open a new file
>step 2: write object Dog to the file.
>step 3: close file
>step 4: open file in append mode. // <-- Problem is here
>step 3: write object Animal to the file.
>step 4: close file
>step 5: open a file in read more.
>step 6: read object Dog
>step 7: read object Animal
>
> Now it is not printing. It is throwing
>java.io.StreamCorruptedException
Serialization does not work the way you are expecting it to work. Appending the file with two separate objects in different streams is not the same as writing two objects in the same stream. Serialization stores some information about the retrieval of the objects which is needed for de-serialization. By writing two separate objects with different streams, the information would not be stored correctly and it would result in a StreamCorruptedException.
You would find the exact information in the Serialization specifications.
Hi,
Thanks for your reply. can you tell me where exactly i can find the details(Which spec page has this info?). It would be better if you give me a link.
I read about serialization here. "http://java.sun.com/docs/books/tutorial/essential/io/serializing.html" . But i dont see the points you mentioned.
I have this kind of requirement. How i can solve this issue? can i have any workaround for this?
Regards,
Mohan
> Hi,
>
> Thanks for your reply. can you tell me where exactly
> i can find the details(Which spec page has this
> info?). It would be better if you give me a link.
>
I don't know if it's in the spec. It's an implementation issue ObjectOutputStream does always write a header at start, and it's that header which corrupts the stream when you try to do an append)
> I read about serialization here.
> "http://java.sun.com/docs/books/tutorial/essential/io/
> serializing.html" . But i dont see the points you
> mentioned.
>
> I have this kind of requirement. How i can solve this
> issue? can i have any workaround for this?
Yes, extend ObjectOutputStream, and create a new constructor which takes a flag which indicates if the header should be written or not (you also have to override some methods so that the header doesn't get written if the flag is false)
Kaj
kajbja at 2007-7-13 12:45:48 >
> Thanks for your reply. can you tell me where exactly
> i can find the details(Which spec page has this
> info?). It would be better if you give me a link.
http://java.sun.com/j2se/1.4/pdf/serial-spec.pdf
> I have this kind of requirement. How i can solve this
> issue? can i have any workaround for this?
The only workaround I know is to read the existing objects and write to the file with the existing + new objects.
> Yes, extend ObjectOutputStream, and create a new
> constructor which takes a flag which indicates if the
> header should be written or not (you also have to
> override some methods so that the header doesn't get
> written if the flag is false)
>
> Kaj
I should have waited before posting my reply.
