About Question enthuware.ocpjp.v7.2.1712 :

[Student]

If you make changes to the class and if you still want old objects to be successfully deserialized into the updated class objects, you should keep the same value for serialVersionUID.

This is illogical. It implies you can have two versions of a class with different data members, but the same serialVersionUID, and that they can be successfully serialized/deserialized to/from each other. Doesn't that beg the question is to why you need to have a serialVersionUID in the first place? If you can make changes to a class and keep the same id, and it won't break, why bother having an id?

[admin]

If you make changes to the class and if you still want old objects to be successfully deserialized into the updated class objects, you should keep the same value for serialVersionUID.

This is illogical. It implies you can have two versions of a class with different data members, but the same serialVersionUID, and that they can be successfully serialized/deserialized to/from each other. Doesn't that beg the question is to why you need to have a serialVersionUID in the first place? If you can make changes to a class and keep the same id, and it won't break, why bother having an id?

No, it is not illogical. This is exactly why you need serialVersionUID. By keeping the serialVersionUID same, you want the serialization mechanism to consider the two versions of the class same. This gives the control to the application developer. This has several practical usages. For example, if you just want to add a new field to a class and yet want to be able to deserialize the objects that were serialized earlier when that field was not present? We use this feature in ETS Viewer.
Of course, just like any other tool, this may be suitable in some cases and not suitable in other.

It will not be possible for me go in too much detail here but you might want to google for it and I am sure you will see that is it quite logical

HTH,
Paul.

[Student]

Okey dokey, I'll take your word for it

[Student]

Um, just took this one again, and, er, got it wrong. This time, having experimented with this a few times recently, to prove to myself that you can add a field to a class without breaking deserialization, I chose

"No special change is necessary in the updated class. Objects serialized earlier will be deserialized to the updated class objects but the newly added field will be null."

To repeat: I've serialized a class, added a field, and deserialized it, and not experienced any problems. In light of that, why is this answer incorrect?

Thanks very much.

[admin]

Not sure how you tested but the following program throws an exception when you try to deserialize:

Code: Select all

import java.io.*;
class A implements Serializable
{
   public String str = "123";
   //public String ptr = "ddd"; //Uncomment this line later while deserializing
}


public class TestClass {

 public static void main(String[] args) throws Exception {
   A a = new A();
   ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("c:\\temp\\a.ser"));
   oos.writeObject(a);
   oos.flush(); oos.close();

   //Comment the above part and uncomment the below part while deserializing
   /*
   ObjectInputStream ois = new ObjectInputStream(new FileInputStream("c:\\temp\\a.ser"));
   A a = (A) ois.readObject();
   System.out.println(a);
   */
 }
}

Output:

Exception in thread "main" java.io.InvalidClassException: A; local class incom
tible: stream classdesc serialVersionUID = -8854535988937765686, local class s
ialVersionUID = -7615702988160566258
at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at TestClass.main(TestClass.java:18)

HTH,
Paul.

[Student]

Not sure how you tested but the following program throws an exception when you try to deserialize:

Yes I think that that's because you're not providing a serialVersionUID. If you don't then the JVM will calculate one for you and embed it. When you subsequently modify the class and deserialize an earlier serialization the JVM will presumably calculate the serialVersionUID again and reconcile it against the one it calculated when it serialized the class.
If you do add a serialVersionUID then (as you've pointed out and as I've tested) you can add a field without any problem as long as you don't change the serialVersionUID.

There's nothing in the statement "No special change is necessary in the updated class. Objects serialized earlier will be deserialized to the updated class objects but the newly added field will be null." that says anything about not having a serialVersionUID. If you put one in, serialize, add a field, and deserialize, then the statement is true....I think.

[admin]

I see what you mean. But you cannot assume that the class has already defined or not defined serialVersionUID . Specially when one of the options is:

It is possible to deserialize the older objects into the update class objects even if the original class did not explicitly define the serialVersionUID field.

HTH,
Paul.

[colmkav]

Why isn't option 3 a valid answer? "No special change is necessary in the updated class. Objects serialized earlier will be deserialized to the updated class objects but the newly added field will be null."

[admin]

Did you read the explanations to option 4 and 5? They explain exactly why 3 is not correct.

[sumanenthu]

In either case, Explicit setting of serialVersionUID or the jvm generated serialversionUID, what will be the value of the newly added field when the deserialization happened?

[admin]

Well, if the serialVersionUID of the class after changes is same (which can be, if you set it explicitly), then the new field will be left with its default value. If it is different, an exception will be thrown.
You should try it out.

-Paul.

[sir_Anduin@yahoo.de]

Well, if the serialVersionUID of the class after changes is same (which can be, if you set it explicitly), then the new field will be left with its default value. If it is different, an exception will be thrown.
You should try it out.

-Paul.

And this is why answer 5 can´t be right:
because you provide no serialVersionUID, so it will be auto generated and differ from the serialized one, when you add a new field.
This is proven by your example, Paul.

This answer would be correct only, if you provice the same serialVersionUID before and after serialization, but you cant know from thee question.

Or am I missing something here?

thanks

Aleks

[admin]

And this is why answer 5 can´t be right:
because you provide no serialVersionUID, so it will be auto generated and differ from the serialized one, when you add a new field.
This is proven by your example, Paul.

This answer would be correct only, if you provice the same serialVersionUID before and after serialization, but you cant know from thee question.

Or am I missing something here?

thanks

Aleks

You need to read option 5 carefully again :
"It is possible to deserialize the older objects into the updated class objects even if the original class did not explicitly define the serialVersionUID field."

Observe that the option is only talking about not defining svid explicitly in the original class. It is not talking about the new updated class. You can find out auto generated svid of the original class and use the same value in the new class.

[sir_Anduin@yahoo.de]

oh, there´s the trick.
find out the old id with "serialver" and use this same id in the updated class.

Thanks a lot

[jagoneye]

Damn I didn't read the last option. I have to salute the makers of this question bank I am amazed at what lengths you have gone to make it! I always get excited when I see such gory and deep questions! The last option is truly the correct option
again thanks to Core Java I luckily read the section describing how Serialization is done and how can you interpret the serialized code(I just read it once the details are too complex to remember) and in that it is explained that without the serialverUID you can serialize and deserialize from newer/older classes without errors but provided the new class doesn't include major changes which in turn cause the default serialversion no calculated to be changed leading to errors or compatibility issues. If someone wants the details of how to interpreting the serialized file then check Streams and Files chapter of Core Java Volume 2.
This question made my day. Keep up the solid work guys! I hope to get my hands on Java 8 exams software in the future if I get a job in this language!

[Badem48]

Hi,

I am confused about one thing.

First can you confirm that if we do not use serialVersionUID with same value and add a new field to the class deserialization will throw an InvalidClassException, right?

For instance;

Code: Select all

import java.io.Serializable;

public class Person implements Serializable {
    private String name;

    public Person(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }
}

Serialize it:

Code: Select all

import java.io.FileOutputStream;
import java.io.ObjectOutputStream;

Person person = new Person("John");
try (FileOutputStream fos = new FileOutputStream("person.ser");
     ObjectOutputStream oos = new ObjectOutputStream(fos)) {
    oos.writeObject(person);
}

Add a filed here:

Code: Select all

import java.io.Serializable;

public class Person implements Serializable {
    private String name;
    private int age; // newly added field

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }
}

Try to deserialize;

Code: Select all

import java.io.FileInputStream;
import java.io.ObjectInputStream;

try (FileInputStream fis = new FileInputStream("person.ser");
     ObjectInputStream ois = new ObjectInputStream(fis)) {
    Person person = (Person) ois.readObject();
    System.out.println(person.getName());
} catch (Exception e) {
    e.printStackTrace();
}

This throws InvalidClassException, because we did not use the same serialVersionUID for the class version control.

So how "Old serialized objects can be deserialized only if the original class had explicitly defined a serialVersionUID field and if the updated class maintains the same value for that field." is the wrong option while "It is possible to deserialize the older objects into the update class objects even if the original class did not explicitly define the serialVersionUID field." option throws an exception?

What am I missing?

[admin]

The updated/new class must have have the same serialVersionUID as the old class. This is true. However, for that too happen, it is not a must for the old class to define it explicitly because even if the old class does not define it explicitly, it still gets a serialVersionUID automatically, which you can get and use in the new class. This is also explained in comment to the last option.

I think that is why this option is marked incorrect but I do also think that this is just making the option too tricky for the exam and should be rephrased.

thank you for your feedback!