Serialization and ClassCastExcpetion

[Brian Snyder]

I have written and complied the following code to practice serialization. When I run it I get a ClassCastException.
Thanks in advance for your assistance.

import java.io.*;
import java.io.Serializable;
import java.util.*;

public class Test implements Serializable {
String str = "Hey now!!!";
int[] ints = {1, -3, -10, 4, 15};
char chars = 'a';
Integer integer = new Integer(10);
public void sendIt() {
try{
FileOutputStream ostream = new FileOutputStream("t.tmp");
ObjectOutputStream p = new ObjectOutputStream(ostream);
p.writeObject(new Test());
p.writeObject(str);
p.writeChar(chars);
p.writeObject(integer);
p.flush();
ostream.close();
} catch (IOException e) { System.out.println("Error writing file");}
}
public void getItt() {
try{
FileInputStream ostream = new FileInputStream("t.tmp");
ObjectInputStream p = new ObjectInputStream(ostream);
String str1 =(String)p.readObject();
int[] ints1 = (int[])p.readObject();
char chars1 = p.readChar();
Integer integer1 = (Integer)p.readObject();
ostream.close();
System.out.println("str1 = " + str1);
System.out.println("str1 = " + ints1);
System.out.println("str1 = " + chars1);
System.out.println("str1 = " + integer1);
} catch (IOException e) { System.out.println("Error writing file");}
catch (ClassNotFoundException e) {System.out.println("Class not found!!!");}

}
public static void main(String[]args) {
Test t = new Test();
t.sendIt();
t.getItt();

}
}

[This message has been edited by Peter Tran (edited April 04, 2001).]

[Peter Tran]

Brian,
You need to de-serialize it in the samer order that you serialized the object.
In sendIt(), you write out:
1. Test() object.
2. String object.
3. A char primitive.
4. An integer wrapper object.
But in getIt(), you try to read in:
1. A string object.
2. An array of integer primitives.
3. A char primitive.
4. An integer wrapper object.
You should modify getIt() to read with the following order:
1. Test() object.
2. String object.
3. A char primitive.
4. An integer wrapper object.
-Peter

[Karthik Guru]

hi,
actually u need to read back the objects in the same order you serialized it.
So,
ObjectInputStream p = new ObjectInputStream(ostream);Test t = (Test)p.readObject();
String str1 =(String)p.readObject();
......
in getIt() should work fine.
I was just wondering , serialization i guess works recursively, so all the data members will also be serialized automatically,
I guess serializing the other data memebers is'nt needed
you can get it back from the Test Object u wrote in.
karthik.

[Anonymous]

You are right, serialization is recursive. Using the ObjectOutputStream you can just write the entire object to disk. Then when you read it back in you can cast it back to the appropriate type of object and access its members individually just as before you stored it. In a situation where everything you want to store lives in the same class, this is a quick and easy solution. If you want to store pieces of different classes, then you have to do things the way you are doing it now: one piece at a time.
[This message has been edited by Bodie Minster (edited April 04, 2001).]

[Brian Snyder]

Thanks everyone.
That answered a big question of mine.
Here's another one. If ObjectInputStream uses readChar() to input a primitive char which needs casting and so does RandomAccessFile, why use one over the other if the result is the same?
[This message has been edited by Brian Snyder (edited April 04, 2001).]

[Karthik Guru]

RandomAccessFile and ObjectOutput/Input streams are'nt 2 different solutions for a problem.
In this case you happened to write the objects(luckily primitives in your case) to a file, somethign which you probably could have done using a RandomAccessFile, but just imagine if you had to say store a "GUI" widget and read it back later..i accept probably does'nt sound intutive, but then you can do it.
using ObjectOutputStream, you can write to a network socket and get the whole object assembled on the other side of the network by doing a readObject(). Infact I feel it's primarily meant to send object across networks using Java's powerful Serialization concept. So there's no file/ anything like that.
Hope i answered your question.
karthik.

[Brian Snyder]

COuld you give me a snippet of code that clarifies your example using

"store a "GUI" widget and read it back later"

? How does the "unfolding" occur when it

on the other side of the network by doing a readObject().

if the receiving end doesn't have the code? I'm green as can be so thanks for your patience!!!

[Karthik Guru]

Yes you are right, u definitely need the class file representing the Object u w'd want to read (on the other side of the network),
but then in RMI they also send in the required class files when required, they (i mean SUN ) know that it's a JVM on the other side of the network as well so they dynamically send the class files too...amazing is'nt it. The client does'nt need to worry about knowing the class files..server will take care of supplying it in runtime through the network!
Again am just a entry-level (1 year) guy in Java, so i'm in no position to comment on other distributed technologies..
okay as for an example.
write a ServerSocket waiting for connections on a port.
You can write a Socket client which w'd connect to that port. Now instead of specifying the FileOutputStream in the
ObjectOutputStream constructor specify,..
the code w'd look something like this..

class MyFrame extends JFrame implements Serializable{
////put some GUI stuff here.
}
//Client
try{
MyFrame f = new MyFrame();
Socket s = new Socket(5000);
ObjectOutputStream os = new ObjectOutputStream(s.getOutputStream());
os.writeObject(f);
os.flush();
}
//
on server...
try{
ServerSocket ss = new ServerSocket(5000); //same machine
Socket s = ss.accept();
ObjectInputStream i = new ObjectInputStream(s.getInputStream());
MyFrame m = (MyFrame)i.readObject();
}
....
Remember the constructor for the Object u just read in w'd never get called. In the sense, u don't construct a new object, you just read in something which has been sent to you.
But Serilaization provides ways to get around this.
i want you to check that out from a tutorial / a book
Now you don't need to "write" a JFrame into a file and then send the file across.

As i mentioned earlier, serializing a widget is probably a foolish idea but then u can get something like that done ..what am actually trying to point out is that you can write in such "huge" objects with just a writeObject().
Now can you imagine writing a JFrame to a file using RandomAccessFile alone and then sending it to someone.
One of the numerous advantage again is that ObjectOutputStream takes the onus of going through your object "recursively", then store it in some fashion, while we developer's have fun.
karthik.

[Brian Snyder]

Thanks Karthik!!!
Your snippet answered my question. See below!!!

try{
   FileOutputStream ostream = new FileOutputStream("t.tmp");
      ObjectOutputStream p = new ObjectOutputStream(ostream);
      p.writeObject(this);
      p.flush();
      ostream.close();
      } catch (IOException e) { System.out.println("Error writing file");}
      }
         public void getItt() {
         try{
         FileInputStream ostream = new FileInputStream("t.tmp");
            ObjectInputStream p = new ObjectInputStream(ostream);
            // Object obj = (Object)p.readObject();  //I was using this instead of....
            Test obj = (Test)p.readObject();  //this...
            String str1 = (String)obj.str;
            int[] ints1 = (int[])obj.ints;
            ostream.close();
            System.out.println("str1 = " + str1);
            System.out.println("ints[2] = " + ints[2]); 
           
            } catch (IOException e) { System.out.println("Error writing file");}
            catch (ClassNotFoundException e) {System.out.println("Class not found!!!");}

}
I know that it is not efficient to write to a file and then send the file. That was quite evident to me. I was just writing to a file as practice, but your explanation of how ObjectOutput/Input is used on a network broadened my horizons even further making me realize the power of Java. Many Thanks!!!