This content has been marked as final. Show 11 replies
serialization requires special help from the jvm. it uses internal jvm magic to create objects without using constructors.1 person found this helpful
ya It must be the case. even the instance blocks and constructors are not getting called when deserializing the object. This mean The object is not getting constructed in a normal way. so it must be jvm specific. so if one jvm serializes it, that cannot be deserialized by a different jvm. Is it true? (Think that I have two jvm's from different organizations. one from oracle and one from IBM).
No. The serialization format is well defined and not VM dependent. You serialize on machine A with VM X and deserialize on machine B with VM Y and you should be ok.1 person found this helpful
The rule is that a Serializable class must inherit only Serializable classes and if not, the first (most recent) non-Serializable ancestor must have the no-args constructor.
This constructor may be explicitly declared or not (in case other constructors are not there, the no-args constructor is an implicit do-nothing constructor).
are u sure about this? it is because we are facing some problem in deserializing an object on android(dalvik vm) which has been serialized by oracle VM(hotspot) the default VM for j2se. and if it is not VM dependent can u explain the logic how an object is being deserialized(constructed back) without calling constructors or initialization blocks. simple explanation is good enough. Thanking you in advance.
also please refer to the following thread as well
Edited by: Muralidhar on Apr 8, 2013 5:15 AM
1 person found this helpful
are u sure about this?I am entirely sure about this. That's precisely what it says in the Object Serialization Specification.
because we are facing some problemWhat problem? If you mean 'the instance blocks and constructors are not getting called', that is correct behaviour.
if it is not VM dependent can u explain the logic how an object is being deserialized(constructed back) without calling constructors or initialization blocks.Because that's what the Specification requires it to do. That's what makes it VM-independent. The specification.
simple explanation is good enough.You don't need an explanation. It's required behaviour. The JVM has to comply. How the JVM accomplishes it isn't relevant. What you need is a solution to your problem, whatever it is.
please refer to the following thread.Why? All it does is state a major error. See my comment there.
Honestly, while I have some Android experience, I don't know if their serialization format is compatible with the official Java's. If it is not, they are kind of stupid, as far as I am concerned, unless someone proves me wrong.1 person found this helpful
Keep in mind that Android != Java. They have a lot in common: syntax and many API-s, but maybe not the serialization format(?). Anyway, the link you mention has a very good point: don't serialize long term using Java's default serialization, it may hunt you when the other component is or may turn to be Android, .NET or whatever.
Thank you so much. The last doubt is again confusion with baftos post. As baftos also says android does not fully comply with java spec could there be any issue with android (dalvik) VM?
Edited by: Muralidhar on Apr 8, 2013 8:07 AM
If it isn't compatible with JDK Serialization it is a bug in Android.
Thank you so much. I am done with my doubt. very clear in mind.
One last doubt I have on serialization is, as object is getting created without calling constructors and initialization blocks in deserialization, does programmer also have a chance to create an object without calling constructors and int blocks? I mean can a programmer will be able to do that?
No.1 person found this helpful
Thank you so much.