aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes How Inheritance Affects Serialization Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "How Inheritance Affects Serialization" Watch "How Inheritance Affects Serialization" New topic
Author

How Inheritance Affects Serialization

Sam Sunamin
Ranch Hand

Joined: Mar 16, 2007
Posts: 113
From K&B's book Chapter 6, it said that if what happens if a superclass is not marked Serializable, but the subclass is.

If you are a serializable class, but your superclass is NOT serializable, then any instance variables you INHERIT from that superclass will be reset to the values they were given during the original construction of the object. This is because the non-serializable class constructor WILL run!

My question is constructor of the superclass WILL run! during serialized or during deserialized? Or both?

Is there any way to walk around it?
In the book, it seems no way to walk round it.

Then what should we do if we really meet this situation in real world?

Thanks in advance.
[ March 30, 2007: Message edited by: Sam Sunamin ]

Yours Sam<br />SCJP5.0 97%<br />SCBCD5.0 72%
Chandra Bhatt
Ranch Hand

Joined: Feb 28, 2007
Posts: 1707
Hi Sam,

If superclass is not serializable but the subclass is, then the construtor of the superclass will run both the times, at the object of the subclass is created (obviously) and secondly when deserialization takes place, first as naturally constructor of the super class is called and then the subclass object is constructed. subclass constructor does not run because the obejct is constructed from the read stream of bytes not from the sub class constructor.

One more thing, superclass must have default constructor so that while deserialization takes place it could be called automatically. Remember if there is no default constructor your constructor can manage to get serialized by calling any other constructor of the superclass, but while deserialization takes place, default constructor is called.


Thanks and Regards,
cmbhatt


cmbhatt
Sam Sunamin
Ranch Hand

Joined: Mar 16, 2007
Posts: 113
I need to know my second question.

Is there any way to walk around it? In the book, it seems no way to walk round it.

Then what should we do if we really meet this situation in real world?
Keith Lynn
Ranch Hand

Joined: Feb 07, 2005
Posts: 2367
This is from the API for ObjectOutputStream.

Serialization does not write out the fields of any object that does not implement the java.io.Serializable interface. Subclasses of Objects that are not serializable can be serializable. In this case the non-serializable class must have a no-arg constructor to allow its fields to be initialized. In this case it is the responsibility of the subclass to save and restore the state of the non-serializable class. It is frequently the case that the fields of that class are accessible (public, package, or protected) or that there are get and set methods that can be used to restore the state.

So you can't stop the superclass(es)'s constructor from running, but you can work around it by storing the data from the nonserializable superclass(es) and restoring it when you deserialize.
Chandra Bhatt
Ranch Hand

Joined: Feb 28, 2007
Posts: 1707
Actually what member variables you inherit from the super class are part of the instance of your class, but when deserialization takes place they are set to the default values. As you may know, you can manually pick the inherited members and serialize them but dont take it as super class instance serialzation but individual only and only when individuals are serializable as if String, Double ,Integer or so are the members of the super class.

"Sam"
What you actually want to know, please give little broad elaboration.

Thanks and Regards,
cmbhatt
[ March 30, 2007: Message edited by: Chandra Bhatt ]
Chandra Bhatt
Ranch Hand

Joined: Feb 28, 2007
Posts: 1707
Originally posted by Srinivasan,


Its interesting to see "How its constructing an Object(which can be casted to specific type) out of ObjectStream."

Something going on behind the scenes...

My Guess:
Serializable classes when compiled may be stuffed with some kind of constructor.

So that while de-serializing it, the readObject can call that specific constructor to init it.



Yeah, it is quite interesting for me too. How object is constructed without calling the constructor. This issue was arisen by one fellow but interestingly nobody took interest in that. I am really much eager to know that. I admire your imagination Srini but we should make it confirmed from any Constructor expert.


With Regards,
cmbhatt
Srinivasan thoyyeti
Ranch Hand

Joined: Feb 15, 2007
Posts: 557
Hi Sam,
Sam:Is there any way to walk around it?
In the book, it seems no way to walk round it.


Don't introspect too much for certification.
First understand different scenarios given in K&B book.
Practice that working or not(Play around the boundaries for now).

Don't look how it was implemented. It will eat your brain.
When book says "It happens like that" just accept the behavior and later you can look into inner-details of Serialization implementation.

Hope this helps you to proceed with Serialization.


Thanks & Regards, T.Srinivasan
SCWCD 1.4(89%), SCJP 5.0(75%)
Srinivasan thoyyeti
Ranch Hand

Joined: Feb 15, 2007
Posts: 557
Hi Chandra,

I thought i was wrong(thats why deleted my post), but seems to be fine.

readObject() returns Object.

How its returning and Object (which can be converted to different types).

One step clear > As it needs to send different types, all types can be encapsulated in Object and can be sent. That thing is ok.

But how the String or Date is re-constructed from bytes without calling constructor ?

There are only two types of Object creation.
1) new SampleClass();
2) Class.forName("SampleClass").newInstance();

I think nobody can escape constructor if needed new Object.
So i can only consider "some special constructor magic done by compiler".

Correct me if i am wrong.
[ March 30, 2007: Message edited by: Srinivasan thoyyeti ]
Chandra Bhatt
Ranch Hand

Joined: Feb 28, 2007
Posts: 1707
Hi Srini,

Your logic seems to be on right path. But we can say it for sure that our serialized class constructor is not called while deserialization takes place. readObject() returns Object that we must cast to particular type ofcourse. readObject()'s job seems like it reads the stream (sequence of bytes) and constitues the object but still question remains at same place. Constructing each member of the object and returning the encapsulated Object is the understood guess.

But as you say, while compiling it may keep the constructor and serialize it. But it is little hard to swallow, until we have strong base on that.

If meanwhile any expert comes, he may solve this puzzle.

With Regards,
cmbhatt
Sam Sunamin
Ranch Hand

Joined: Mar 16, 2007
Posts: 113
Hi Srinivasan,

I think your logic is right. Just accept what they said in the book and thus focused on the exam. When I need it in the real world, I will figure out how to do it.

Thank you for all your reply.
Keith Lynn
Ranch Hand

Joined: Feb 07, 2005
Posts: 2367
Here is an example to illustrate how to do it.



This is the output without those two special methods.



This is the output with those two special methods.

Sam Sunamin
Ranch Hand

Joined: Mar 16, 2007
Posts: 113
Hi Keith ,

Cool, man. I have tested it. It works. Thank you so much for the solution.

[ March 30, 2007: Message edited by: Sam Sunamin ]
[ March 30, 2007: Message edited by: Sam Sunamin ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How Inheritance Affects Serialization