File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Beginning Java and the fly likes serialization Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "serialization" Watch "serialization" New topic


Sandeep Shukla

Joined: Oct 21, 2004
Posts: 5
class A implements Interf,Serializable

A is serialized
Then A is to be deserialized

A is removed from class path
//Map it to obect
Object o = in.readObject()
Map it to interface Interf
Interf c =(Interf) in.readObject()

tell me w.r.t compile time and run time errors, if any
Ernest Friedman-Hill
author and iconoclast

Joined: Jul 08, 2003
Posts: 24199

Hi Sandeep,

Welcome to JavaRanch!

To deseriallize an object, you need the .class file corresponding to the object's class -- whether you name the class in your deserialization source code or not. There are some versioning mechanisms that form part of the Serialization API, so that the .class file doesn't necessarily have to be the exact same one. But you do need to have a compatible class file available.

[Jess in Action][AskingGoodQuestions]
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
The JavaDoc for readObject() would I guess give you the information you want.

public final Object readObject()
throws IOException,
ClassNotFoundExceptionRead an object from the ObjectInputStream. The class of the object, the signature of the class, and the values of the non-transient and non-static fields of the class and all of its supertypes are read. Default deserializing for a class can be overriden using the writeObject and readObject methods. Objects referenced by this object are read transitively so that a complete equivalent graph of objects is reconstructed by readObject.
The root object is completely restored when all of its fields and the objects it references are completely restored. At this point the object validation callbacks are executed in order based on their registered priorities. The callbacks are registered by objects (in the readObject special methods) as they are individually restored.

Exceptions are thrown for problems with the InputStream and for classes that should not be deserialized. All exceptions are fatal to the InputStream and leave it in an indeterminate state; it is up to the caller to ignore or recover the stream state.

Specified by:
readObject in interface ObjectInput
the object read from the stream
ClassNotFoundException - Class of a serialized object cannot be found.
InvalidClassException - Something is wrong with a class used by serialization.
StreamCorruptedException - Control information in the stream is inconsistent.
OptionalDataException - Primitive data was found in the stream instead of objects.
IOException - Any of the usual Input/Output related exceptions.

Compiletime: only if A.class or can't be found during compilation.
Runtime: probably a ClassNotFoundException because the real class (A) of the streamed data is unavailable. Casting it to Interf likely doesn't matter one iota to readObject() as it only happens AFTER readObject() completes.
Therefore readObject() will need to find A.class on the classpath.

Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
P.S. You can override ObjectInputStream to do class substitution during deserialisation, but whether this prevents the need for the original class I don't know (in fact I severely doubt it).
I agree. Here's the link:
subject: serialization
It's not a secret anymore!