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?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.
About Question enthuware.ocpjp.v7.2.1712 :
Moderator: admin
-
- Posts: 53
- Joined: Fri Sep 20, 2013 7:20 am
- Contact:
About Question enthuware.ocpjp.v7.2.1712 :
-
- Site Admin
- Posts: 10046
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
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.Student wrote: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?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.
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.
If you like our products and services, please help us by posting your review here.
-
- Posts: 53
- Joined: Fri Sep 20, 2013 7:20 am
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
Okey dokey, I'll take your word for it
-
- Posts: 53
- Joined: Fri Sep 20, 2013 7:20 am
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
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.
"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.
-
- Site Admin
- Posts: 10046
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
Not sure how you tested but the following program throws an exception when you try to deserialize:
Output:
Paul.
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);
*/
}
}
HTH,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)
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 53
- Joined: Fri Sep 20, 2013 7:20 am
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
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.admin wrote:Not sure how you tested but the following program throws an exception when you try to deserialize:
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.
-
- Site Admin
- Posts: 10046
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
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:
Paul.
HTH,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.
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 21
- Joined: Thu Jul 16, 2015 4:22 am
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
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."
-
- Site Admin
- Posts: 10046
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
Did you read the explanations to option 4 and 5? They explain exactly why 3 is not correct.
If you like our products and services, please help us by posting your review here.
-
- Posts: 23
- Joined: Sun Feb 21, 2016 10:12 am
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
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?
-
- Site Admin
- Posts: 10046
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
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.
You should try it out.
-Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 62
- Joined: Fri Aug 07, 2015 2:16 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
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
-
- Site Admin
- Posts: 10046
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
You need to read option 5 carefully again :sir_Anduin@yahoo.de wrote:
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
"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.
If you like our products and services, please help us by posting your review here.
-
- Posts: 62
- Joined: Fri Aug 07, 2015 2:16 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
oh, there´s the trick.
find out the old id with "serialver" and use this same id in the updated class.
Thanks a lot
find out the old id with "serialver" and use this same id in the updated class.
Thanks a lot
-
- Posts: 97
- Joined: Wed Dec 28, 2016 9:00 am
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
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!
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!
-
- Posts: 26
- Joined: Thu Aug 24, 2023 4:33 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
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;
Serialize it:
Add a filed here:
Try to deserialize;
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?
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;
}
}
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);
}
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;
}
}
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();
}
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?
-
- Site Admin
- Posts: 10046
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1712 :
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!
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!
If you like our products and services, please help us by posting your review here.
Who is online
Users browsing this forum: No registered users and 62 guests