Serialization

[Puja Sinha]

Hi,

In the following code when we deserialize the dog object the Animal class constructor is run and the weight variable gets the value of 42 instead of the value it had when the dog object was serialized.

But when we serialize the dog object is the value of the inherited weight variable also saved or not ?

class Dog extends Animal implements Serializable {
    String name;
    Dog(int w, String n) {
        weight = w; // inherited
        name = n; // not inherited
    }
}
class Animal { // not serializable !
    int weight = 42;
}

Thanks in adv.

[Swastik Dey]

when we deserialize the dog object the Animal class constructor is run and the weight variable gets the value of 42 instead of the value it had when the dog object was serialized.

public static void main(String...arg){
		try{
			Dog d=new Dog(10,"Tommy");
			ObjectOutputStream os=new ObjectOutputStream(new FileOutputStream("c:\\mfile.obj"));
			os.writeObject(d);
			os.flush();
			os.close();
			ObjectInputStream is=new ObjectInputStream(new FileInputStream("c:\\mfile.obj"));
			Dog d1=(Dog)is.readObject();
			System.out.println(d.weight);
		}
		catch(Exception e){}
	}

What I am getting is 10 not 42, as you are saying.

[Puja Sinha]

Swastik,

Print d1.weight and you will get 42

[Swastik Dey]

Puja,

Yes you are right. As per my understanding the state of the object is saved, but the variable weight belongs to the non-serialized class, and thats why not persisted. If you declare another instance variable with the same name in Dog class, you should get the saved state. Correct me if I am wrong.

class Dog extends Animal  implements Serializable {
    String name;
    int weight;
    Dog(int w, String n) {
        weight = w; // inherited
        name = n; // not inherited
    }
}
class Animal { // not serializable !
    int weight = 42;
}

public class Sl{
	public static void main(String...arg){
		try{
			Dog d=new Dog(10,"Tommy");
			ObjectOutputStream os=new ObjectOutputStream(new FileOutputStream("c:\\mfile.obj"));
			os.writeObject(d);
			os.flush();
			//os.close();
			ObjectInputStream is=new ObjectInputStream(new FileInputStream("c:\\mfile.obj"));
			Dog d1=(Dog)is.readObject();
			System.out.println(d1.weight);  //10
			System.out.println(d1.name);
		}
		catch(Exception e){}
	}
}[code=java]

[/code]

[Tommy Delson]

Swastik Dey wrote:Puja,

Yes you are right. As per my understanding the state of the object is saved, but the variable weight belongs to the non-serialized class, and thats why not persisted. If you declare another instance variable with the same name in Dog class, you should get the saved state. Correct me if I am wrong.

That's INCORRECT "If you declare another instance variable with the same name in Dog class, you should get the saved state. Correct me if I am wrong."

If you Inherited "weight" from Animal you shouldn't declare a new instance variable. If you declared a new instance variable in Dog class then the instance variable you Serialized is belong to a Dog class not Animal class that you inherited.

In other word, you just create an instance variable "weight" with the same name with Animal class, that meant you didn't utilize the inherit "weight" instance variable in Animal.

The RULE and a RECAP from K&B book:

If a superclass is Serializable, then according to normal Java interface rules, all subclasses of that class automatically implement Serializable implicitly. In other
words, a subclass of a class marked Serializable passes the IS-A test for Serializable, and thus can be saved without having to explicitly mark the subclass as Serializable.

You simply cannot tell whether a class is or is not Serializable UNLESS you can see the class inheritance tree to see if any other superclasses implement Serializable. If the class does not explicitly extend any other class, and does not implement Serializable, then you know for CERTAIN that the class is not Serializable, because class Object does NOT implement Serializable.


Let me know if that make sense...

[Tommy Delson]

I've modified the code to more comprehensive that cover most of all aspect of Serialization. Have a look and see what you think then run, and test the code for more insight.

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;

class Dog extends Animal  implements Serializable {

    String name;
    //int weight; //No need to declare "weight" since you inherited from Animal
    			  //If you declared, this instance variable belong to Dog not Animal.

	static int a = 5; int b = 4; //Are these variables saved as part of the object's state ???
	transient int x = 8; //Does x saved as part of the object's state?

	int y = 15;


    Dog(int w, String n) {
        weight = w; // inherited from Animal
        name = n; // not inherited
    }

}

class Animal { //Animal class doesn't implements Serializable

    int weight = 42;
}

public class SerializationTest {

	public static void main(String...arg){

		//Best practice place non serialization codes outide the try/catch blocks
		Dog d = new Dog(10,"Tommy"); //Initialize Dog's object with (10,"Tommy")

		//Assign new values to instance variables
		d.a = 14;
		d.b = 17;
		d.y = 21;

		//What ouput values do you think before serialization?
		System.out.println("Before: "+ d.weight + "," + d.name);
		System.out.println("a before: " + d.a + " b before: " + d.b);
		System.out.println("x before: " + d.x);
		System.out.println("y before: " + d.y);

		try{ //Best practices have a try/catch block for Serialization

			ObjectOutputStream os=new ObjectOutputStream(new FileOutputStream("c:\\mfile.obj"));
			os.writeObject(d); //Serialize the Dog's object with (10,"Tommy") and other
			os.flush();
			os.close();

		}catch(Exception e){

			System.out.println("Serialization fail."+ e);

		}

		try{ //Best practices have a try/catch block for Deserialization

			ObjectInputStream is=new ObjectInputStream(new FileInputStream("c:\\mfile.obj"));

			//Bad practice: Wrong way of doing by create a NEW Dog reference "d1". Now "d1"
			//reference variable points to the ORIGINAL Dog's object state with (10,"Tommy") and others
			//So you'll get a result just like before Deserialization.
			//It should be "d" instead of "d1" that you assign Deserialized object. Othwerwise you'll
			//get the wrong result.
			//Dog d1=(Dog)is.readObject(); //No No, BAD practice!

			//Same "d" now pointing to the Dog's deserialized object
			d =(Dog)is.readObject(); //Correct way of deserialization

			is.close();

		}catch(Exception e){

			System.out.println("Deserialization fail"+ e);
		}

		//What ouput values do you think after deserialization? If different than before then WHY?
		System.out.println("After: "+ d.weight + "," + d.name);
		System.out.println("a after: " + d.a + " b after: " + d.b);
		System.out.println("x after: " + d.x);
		System.out.println("y after: " + d.y);

		/*

		 If you don't get the right result then I recommend you NEED to reread the K&B book on Serialization
		 to reinforce until you get them right. 

		*/

	}
}

[Bert Bates]

great discussion, just a note:

Officially, serialization has been removed from the exam. At this point it's unlikely (but remotely possible), that you'll get any questions on serialization in the real exam.

But, it's still a really good topic to understand

[Andreas Svenkson]

Tommy Delson wrote:

Swastik Dey wrote:Puja,

Yes you are right. As per my understanding the state of the object is saved, but the variable weight belongs to the non-serialized class, and thats why not persisted. If you declare another instance variable with the same name in Dog class, you should get the saved state. Correct me if I am wrong.

That's INCORRECT "If you declare another instance variable with the same name in Dog class, you should get the saved state. Correct me if I am wrong."

No, that's perfectly correct. By declaring a new instance variable with the same name, one is shadowing/hiding the inherited variable. The "new" member variable is indeed part of the new object, which is serializable, and therefor that variable will be saved and restored. But the inherited variable is still there, accessible via inheritance, and not restored - which I believe is exactly what Swastik was saying.

// Andreas

[Tommy Delson]

Andreas Svenkson wrote:

Tommy Delson wrote:

Swastik Dey wrote:Puja,

Yes you are right. As per my understanding the state of the object is saved, but the variable weight belongs to the non-serialized class, and thats why not persisted. If you declare another instance variable with the same name in Dog class, you should get the saved state. Correct me if I am wrong.

That's INCORRECT "If you declare another instance variable with the same name in Dog class, you should get the saved state. Correct me if I am wrong."

No, that's perfectly correct. By declaring a new instance variable with the same name, one is shadowing/hiding the inherited variable. The "new" member variable is indeed part of the new object, which is serializable, and therefor that variable will be saved and restored. But the inherited variable is still there, accessible via inheritance, and not restored - which I believe is exactly what Swastik was saying.

// Andreas

@Andreas

Your statement about "shadowing" only true when you apply to Local Variables Declaration. Recap from K&B book "It is legal to declare a local variable with the same name as an instance variable; this is called "shadowing." ". See page 255 for more details.

Again, here we're dealing with Serialization and Inheritance, you tried to Serialize and Deserialized Dog and superclass that Dog extends which is Animal. In this case, Animal's instance variable is a variable that Dog inherited so, Dog doesn't need to declare or create NEW instance variable. Sure, you can DECLARE or CREATE new instance variable "weight" in Dog class, but...

Here is a CATCH: What class that "weight" Newly Created instance variable belong too? Well, of course belong to the DOG right?

Alright, so if the newly created instance variable "weight" is belong to Dog so, "weight" instance variable in Animal class is NO longer being inherited or utilized right? The POINT here is we want the inherited "weight" instance variable in Animal class, if you created a new instance variable in Dog class so it shadowing the "weight" instance variable in Animal. That meant really you just USE your own instance variables instead of inherited from Animal.

So why would you do that if you already have "weight" already declared in Animal class? Isn't it a redundancy? Here the question asking what's the result of weight in Animal class before serialization and after deserialization?

It's NOT asking how you shadowing the instance variable. Do see why Sinha asked why "weight variable gets the value of 42 instead of the value it had when the dog object was serialized. " ??? That's the POINT, the weight variable result with the value 42 simply Animal class doesn't implements Serializable interface so, the constructor of Animal class is called and all instance variable value of Animal class reinitialized to it original state. Remember Dog extends Animal and Animal is in Dog's Object Graph.

Recap from K&B book: What if the instance variables are themselves references to objects? What gets saved?

Now what happens if you save the Dog? If the goal is to save and then restore a Dog, and the restored Dog is an exact duplicate of the Dog that was saved, then the Dog needs a Collar that is an exact duplicate of the Dog's Collar at the time the Dog was saved. That means both the Dog and the Collar should be saved.

And what if the Collar itself had references to other objects—like perhaps a Color object? This gets quite complicated very quickly. If it were up to the programmer to know the internal structure of each object the Dog referred to, so that the programmer could be sure to save all the state of all those objects…whew.

That would be a nightmare with even the simplest of objects. Fortunately, the Java serialization mechanism takes care of all of this. When you
serialize an object, Java serialization takes care of saving that object's entire "object graph." That means a deep copy of everything the saved object needs to be restored.

For example, if you serialize a Dog object, the Collar will be serialized automatically. And if the Collar class contained a reference to another object, THAT object would also be serialized, and so on. And the only object you have to worry about saving and restoring is the Dog. The other objects required to fully reconstruct that Dog are saved (and restored) automatically through serialization.

For more information you can reread K&B book on topic "Object Graphs" on page 500, from there you can tell whether it makes sense or not.

[Andreas Svenkson]

I think you are actually agreeing with what I and Swastik said, atleast if I get you right

If so we can agree on the following:

1: The inherited weight var from Animal will not be restored when deserializing a Dog object. Instead, the dog will have a weight variable with the value of 42, since it has been reinitialized in the Animal class - just as Swastik said.
2: We can shadow/hide the inherited variable (for whatever reason), resulting in a new variable in the Dog class with the same name. This one would be both serialized/deserialized upon doing so on a Dog object.

Now, whether or not one should/would want to hide an inherited variable like this, is a different discussion. Swastik only brought it up because that is the only way in which deserializing a Dog object would also deserialize the (new) weight variable.

// Andreas

[Tommy Delson]

Andreas Svenkson wrote:I think you are actually agreeing with what I and Swastik said, atleast if I get you right

If so we can agree on the following:

1: The inherited weight var from Animal will not be restored when deserializing a Dog object. Instead, the dog will have a weight variable with the value of 42, since it has been reinitialized in the Animal class - just as Swastik said.
// Andreas

NO, 110% totally DISAGREE! Here is why...

First I'm not sure you quite understood my explanation on earlier post or not, and second are you really totally UNDERSTAND the concept? Based on what you have said I don't think you quite UNDERSTOOD my explanation and the concept at all, no offend.

I'm think you are not EVEN run the code I proposed, tested, and see what it behaved. I don't blame you on that, but if you could do try RUNNING and TEST the code before given out your comments. To confirm whether it make sense or not, run and test the CODE, the COMPILER won't lie and will tell you the TRUTH result. Correct me if I'm wrong...

Here is why and again, the "inherited weight var from Animal will not be restored when deserializing a Dog object" because you are NOT inherited if you declared instance var "weight" in Dog class plus Animal class doesn't implements Serializable.

Totally INCORRECT, "Instead, the dog will have a weight variable with the value of 42, since it has been reinitialized in the Animal class - just as Swastik said."

Making NO SENSE, where do the DOG getting a value 42 from since Dog NOT inherited "weight" var from Animal if you declared "weight" instance variable in Dog class. Look AGAIN, the Dog class will have the "weight" value of 10 passed from Dog's constructor on line 36 an instantiation of a Dog instance (i.e Dog d = new Dog(10,"Tommy") before a Serialization start. Value 10 this is what you're passing and stored in Dog's instance var "weight" NOT value 42. Do you see it?

If you're not CONVINCE try to RUN the code in the First try and comment out "weight" var in Dog's class like it already have, check the output weight value and see what RESULT do you get.

Next, uncomment the "weight" var and RUN the code again, check the output weight value and see what RESULT do you get. The COMPILER won't lie so, you'll get the RESULT of what it supposed to.

2: We can shadow/hide the inherited variable (for whatever reason), resulting in a new variable in the Dog class with the same name. This one would be both serialized/deserialized upon doing so on a Dog object.

Yes, I agree if you CHOSE to do this way, but it make NO SENSE in perspective of inheritance. Let's say down the road you have a subclass of Dog called Lacy that you tried to implements Serializable and Lacy wants to inherits "weight" instance var from an Animal class not from Dog class. So if you shadowed the "weight" var in Dog class how in the world Lacy ables to have a value 42 from Animal class when doing Serialization and Deserialization???

Even that what if you have another subclass of Lacy want to inherits "weight" in the Animal class. Do you see the big MESS??? Don't tell me you gonna declare another "weight" instance" variable in Lacy class to shadow the "weight" var in the Dog class.

In the REAL world application if you doing this you'll have a NIGHTMARE to maintain the code and FIGURE out what went wrong with your application when the RESULT you want to get is INCORRECT. I'm sure your COMPANY or CLIENT ain't happy about this...

If it's not convince you, you can try coding on scenarios I stated above to confirm, the Compiler won't lie.

Now, whether or not one should/would want to hide an inherited variable like this, is a different discussion. Swastik only brought it up because that is the only way in which deserializing a Dog object would also deserialize the (new) weight variable.

In summary, Serialization is the process of writing complete state of java object into output stream, that stream can be file or byte array or stream associated with TCP/IP socket.

Having said all that, I think to this POINT you should know and understand better about Serialization and Deserialization.

I'm NEW to Serialization too, but through coding and experiment I can CONFIRM that the Compiler won't lie.

Peace...

[Achilleas Achix]

Tommy,
just point Andreas to the exact page of the book or other documentation about serialization. No need to get emotional or write whole essays, especially about concepts which :
a) have been beaten to death here in the forums
b) are not even in the exam