Check out my kickstarter CLICK HERE
My book, my movies, my videos, my podcasts, my events ... the big collection of paul wheaton stuff!
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
"I'm not back." - Bill Harding, Twister
Originally posted by Jim Yingst:
It's not clear to me how your last post establishes that there's not a versioning problem of some sort. Unless you mean that you checked this carefully, though the details of the check are not shown here.
I'm pretty sure this isn't the problem: the pseudo code for the process follows. There's no threading, or anything fancy going on.
line 1: serializeA(a,"A.ser");
line 2: A aTmp = (A)serializeA("A.ser");
Are the serialization and de serialization occurring in the same VM? Is there any possiblity that class B is being loaded by two different class loaders, maybe even using different Jar files?
Yes. No, no.
It may be worthwhile to check your classpaths very carefully.
Good suggestion: I tried this, but I didn't see anything weird.
You might try changing JDks a bit, to see if maybe there's just a bug in the current version you're using.[/QB]
I'll give it a shot, thanks.
[ June 30, 2004: Message edited by: Max Habibi ]
Originally posted by David O'Meara:
I'm trying to imagine how it would create the outcome you're seeing, but are you working with a single or multiple ClassLoaders?
"I'm not back." - Bill Harding, Twister
Originally posted by Jim Yingst:
Well congratulations, Max. You've got yourself a very weird problem.
Thanks, her mother and I are so proud.
I assume in your pseudocode above, line 2 should deserialize A.ser, is that right?
yes.
Does either A or B implement Externalizable? Are there readExternal() and writeExternal() methods somewhere in its hierarchy? If so, it sounds like there's a bug in one or the other.
no, no, thought I'm considering such as a solution.
More generally, are you using the serialization provided by ObjectOutputStream and ObjectInputStream, or something else - like say, XStream?
ObjectOutputStream and ObjectInputStream
You say you can serialize and deserialize a B instance by itself. Are you sure you get back the same thing? Do
originalB.equals(deserializedB)
and
originalB.getClass() == deserializedB.getClass()
evaluate to true?
Didn't think to check that: will do. What are you thinking here?
Where does the top of the stack trace from the ClassCastException point? Is it deep inside ObjectOutputStream's readObject()? Or somewhere else? Can you find the source for the line that's throwing the exceptio? Probably not if it's inside native code, but maybe you'll get lucky...
It seems to be at Class A#B, so I'm assuming it's where it actually tries to read B.
As an aside, it's a recurring annoyance that many exceptions thrown by library classes don't bother to include pertinent info. E.g. a FileNotFoundException usually won't include the name of the file you were looking for. Or in this case, a ClassCastException doesn't usually name the two classes involved.
Well, it does indicate that it's trying to cast it to a String: I'm guessing String is the default type it tries when it doesn't know what to do.
"I'm not back." - Bill Harding, Twister
42
I just had the craziest dream. This tiny ad was in it.
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|