• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Serialization and ClassCastExcpetion

 
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

[This message has been edited by Peter Tran (edited April 04, 2001).]
 
Bartender
Posts: 783
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Karthik!!!
Your snippet answered my question. See below!!!

}
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!!!
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic