deserialization problem

[urbanleg]

Hi, i would like to transfer serialized classes over to a client host.

i have 1 base class - "BASE"
and 10 derived classes - "DERIVED1" , "DERIVED2", "DERIVED3" ...

is it possible to serialize DERIVED1, send it to client, deserialize it at client side, and finally cast it to BASE?

(this way i save the client side from declaring DERIVED1,DERIVED2,....which are extremely big and complex. this will grant me an "UBER" simplified client which is my goal)

IMPORTANT: I DO need the BASE Fields\methods only on the client side so information loss is irrelevant for the DERIVED classes at the client side.

thanks!

[Norm]

I think it should work. The default class for the received object is Object with all classes are derived from.

Write a short simple program to test it and let us know what happens.

[urbanleg]

ok so, the client recives a DERIVED class named UNKNOWNPROBLEM and tries to deserialize it with the line:

Problem responseProb = (Problem) ois2.readObject();

here, PROBLEM is the BASE class i want to cast into.

again, the client side only defined PROBLEM and doenst know or care about UNKNOWNPROBLEM (and thats why i get the following exceptions:)

Exception in thread "main" java.lang.ClassNotFoundException: Problem.UnknownProblem
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at java.io.ObjectInputStream.resolveClass(Unknown Source)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unkno wn Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at Client.Client.reciveResponseFromServer(Client.java :100)
at Client.Client.main(Client.java:68)

[Norm]

The names of classes and packages you show are all different and are confusing and not clear.
The case makes a difference.
Is the package name the same as the class name? Problem

[urbanleg]

yes sir. the name of the package is indeed problem as well

[Norm]

class named UNKNOWNPROBLEM
is not the same as
UnknownProblem

[urbanleg]

UNKNOWNPROBLEM stand for UknownProblem.
i tried to make it in caps since its important

the names are identical

[Norm]

Case is very important when dealing with class names.

Do you have a small test program that compiles and executes that you could post to demonstrate the problem?

[urbanleg]

ofcourse.
there is no class named UNKNOWNPROBLEM in my project only UnknownProblem.

keep in mind the client which de serialize doesnt have it and hence the unknown class exception.
what i ask is: do the client must know the class UnknowProblem in order to deserialze?
i rather him knowing only Problem and upcasting all the derived classes he get.
and using only BASE functions

[Norm]

I have never done it, so I can not say what will happen. Can you write a test program to see.

Then we will both learn something.

[urbanleg]

the question standing at hand is:

"when deserializing a DERIVED class, do i must have the exact derived class declared or can i deserialize(and cast) it as BASE?"

my intuition says that serialization need to have the concrete derived class since the case i worte in the question might lead to information loss

[Norm]

Makes sense. The readObject() method would need a definition for the class it is reading to be able to reconstruct it.

[urbanleg]

thanks for your time:)

[Norm]

Another idea for a test. Make some dummy skeleton class definitions for the derived classes and see what happens.

[urbanleg]

ill give it a shot. thanks

[Tolls]

If you take a peek in the output of a serialised object you'll see near the beginning the (rather mangled in text) classname, which is used by the deserialiser to identify what it is it's supposed to be creating. So you can't use serialisation for this.

Web Services (WSDL) gets around this by simply defining the interface (methods and data required by those methods), and transmitting a standardised lump of xml between client and server. Each end defines its own concrete versions of these interfaces and handles the translation from XML to something "real".