Page 1 of 1
About Question enthuware.ocpjp.v7.2.1620 :
Posted: Sat Sep 28, 2013 12:00 pm
by Student
However, since f4 is being initialized as a part of class initialization, it will be initialized to the same value in another JVM. Thus, its value will be preserved.
What if in the intervening time period f4's declaration is changed from this:
public final static String f4 = "4";
to this:
public final static String f4 = "5";
? Will f4's value be preserved?
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Sat Sep 28, 2013 12:27 pm
by admin
No, if you change the code then it won't be preserved. In fact, in that case, you may even get an exception while deserializing because the serialVersionUID might be different (not necessarily, but might be) after the code change. You have to check it out.
HTH,
Paul.
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Tue Jan 20, 2015 3:04 am
by disznoperzselo
The correct answer is that it won't compile because it tries to assign a String to d.f2 of type int. Read the text carefully on the exam.
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Tue Jul 14, 2015 12:57 pm
by ewebxml
I selected c), but the explanation says for option b)
Code: Select all
public final static String f4 = "4";
However, since f4 is being initialized as a part of class initialization,
it will be initialized to the same value in another JVM.
General Rule:
Transient fields are not serialized.
static fields are not serialized.
Can I safely say as an exception to the rule:
Exception:
If a static field is being initialized as a part of class initialization,
it will be initialized to the same value in another JVM.
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Tue Jul 14, 2015 5:55 pm
by admin
ewebxml wrote:I selected c), but the explanation says for option b)
Code: Select all
public final static String f4 = "4";
However, since f4 is being initialized as a part of class initialization,
it will be initialized to the same value in another JVM.
General Rule:
Transient fields are not serialized.
static fields are not serialized.
Can I safely say as an exception to the rule:
Exception:
If a static field is being initialized as a part of class initialization,
it will be initialized to the same value in another JVM.
I wouldn't call it an exception. static fields are not serialized. There is no exception to this rule. A static field that is initialized as a part of class initialization will be initialized when the class is loaded in any jvm. This part has nothing to do with serialization.
-Paul.
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Sat May 21, 2016 8:11 pm
by codecodecode67
if the line
was changed to
Code: Select all
public static String f1 = "someString";
Would f1 also be initialized to "someString" in another JVM regardless of the fact that it's not declared final?
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Sat May 21, 2016 8:13 pm
by admin
codecodecode67 wrote:if the line
was changed to
Code: Select all
public static String f1 = "someString";
Would f1 also be initialized to "someString" in another JVM regardless of the fact that it's not declared final?
Yes. final has nothing to do with it.
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Sat May 21, 2016 8:22 pm
by codecodecode67
Got it!
I'm sorry if this is an annoying question, but if line
was changed to
Code: Select all
public transient String f1 = "someString";
Would f1 then be initialized to "someString" in another JVM regardless of the fact that it's not declared transient? - in my mind it shouldn't..?
Edit - some new information below
When a transient final field member is initialized to a constant expression as those defined in the JLS 15.28. Hence, field members declared this way would hold their constant value expression even after deserializing the object. I guess that is so because the value of the final field is actually a constant expression as described by the JLS.
Which leads me to think that the without the final modifier, the static field's constant value will not be preserved although it's a static field - it's not a constant field if it's not 'final'.
Please let me know your thoughts.
Thanks!
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Sat May 21, 2016 9:00 pm
by admin
No, it will not be initialized to "someString" because f1 is transient and therefore the value will not be present in the serialized data.
Further, since constructors and instance initializers of a class are NOT executed when an object of that class is deserialized, f1 will not be given the value of "someString" automatically.
Here are the exact details of the steps that are taken by the JVM when it serializes and deserializes an object:
https://docs.oracle.com/javase/8/docs/p ... alTOC.html
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Wed Jan 18, 2017 6:42 am
by jagoneye
I think only f4 should be the answer.
Because if you say so then even those other static fields are preserved because even if you deserialize in another jvm those static fields will get the same default values which is null for non-primitive objects, false for boolean and likewise.
Even then if you say I'm wrong then I argue that still those static fields value will not be preserved because say if you have something like this:
Code: Select all
static int j = 5;
static
{
j = 6;
}
So in this case the static initializer blocks will be executed as soon as the class is loaded regardless of deserialization and that means the original value of j=5 will be lost and changed to 6 unlike in case of non-static variables for which initialization blocks are not executed in the classes which implement Serializable.
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Wed Jan 18, 2017 10:17 am
by admin
I am not sure I understand your point but the answer given in the question and the explanation are correct.
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Sun Aug 20, 2017 6:48 am
by rolandlensink
static fields are serialized, only a static field is serialized with the last value at the moment of serialization.
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Sun Aug 20, 2017 11:10 am
by admin
Where did you read that?
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Sun Aug 20, 2017 4:33 pm
by rolandlensink
I found out by experience ... try it yourself ...
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Mon Aug 21, 2017 1:42 am
by admin
Would you consider the possibility that you may be drawing wrong inference from whatever test program your wrote and ran?
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Tue Dec 25, 2018 12:33 am
by lennychapfuwa
for sure the answer is b. note that f1, f2, f3 and f4 will not be serialized, but only f5 will be serialized. however f1,f2 and f3 have been given new values which will be defaulted to the following at deserialization, f1 = null f2 = null, f3 = false. f4 will remain "4" and f5 will remain "5" at deserialization.
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Sun Mar 03, 2019 4:58 pm
by crazymind
Say we have "public static String f6 = "f6";" inside class Data, then use d.f6 = "f6 changed"; to change f6. Is f6 changed? I understand that static is not serialized and JVM load class with f6's initial value. So I guess it is not changed. And is f1 print null after deserialization?
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Sun Mar 03, 2019 9:40 pm
by admin
What happened when you tried it out?
Post complete code.
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Sun Dec 08, 2019 6:18 am
by Bhaskar
So in short can it be said that, since f1, f2 and f4 are static, their values will be maintained after de-serialization only if performed in the same JVM, and If de-serialized in another JVM, the values of f1,f2,f3 will be lost and only f4 will be maintained because of class initialization? Please verify.
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Sun Dec 08, 2019 11:38 am
by admin
That's correct.
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Wed Mar 31, 2021 3:38 pm
by jme_chg
So just to confirm:
If it's an instance variable
- if initialized, it will always have same value when serialized and deserialized, regardless of whether in same JVM or not.
- if not initialized, it will always take default value when serialized and deserialized, regardless of whether in same JVM or not.
If it's a transient variable, it will always take default value when serialized and deserialized, regardless of whether initialized/uninitialized or whether in same JVM or not.
If it's a static variable then:
- if initialized, it will always have same value when serialized and deserialized, only when in a different JVM.
- if not initialized, it will always take default value when serialized and deserialized, regardless of whether in same JVM or not.
If variable is both static and transient, apply static rules.
?
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Thu Apr 01, 2021 1:50 am
by admin
It is hard to confirm such things because there are too many ifs in there. But in general, it looks ok. I wouldn't recommend anyone to bank on the above rule book though.
Re: About Question enthuware.ocpjp.v7.2.1620 :
Posted: Thu Apr 01, 2021 11:17 am
by jme_chg
You're right, so many ifs that I made a mistake,
I think it can simply be generalised to:
INSTANCE/STATIC VARIABLES:
After both serialized/deserialized, same value if initialised, default value if not initialised (regardless of JVM).
TRANSIENT VARIABLES:
After both serialized/deserialized, always default value (regardless of JVM).
If variable both static and transient, apply static rule.
To me, it looks like instance/static variables behave the same - the only difference is that for statics, they don't get serialized in between...
Correct me if I'm wrong please.