This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
De-serialization is the process of constructing the object from the byte stream.
So while de-serializing the JVM should read/parse the byte stream and create the object and set the property at run-time.
But at the time of de-serialization, the object constructor won't be called.
Please clarify me "How the objects are created while de-serialization?"
( Because the constructor won't be invoked. If it uses reflection the constructor will be called. )
Thennam Pandian wrote:I am sure, it won't call default constructor.
During deserialization, the fields of non-serializable classes will be initialized using the public or protected no-arg constructor of the class. A no-arg constructor must be accessible to the subclass that is serializable. The fields of serializable subclasses will be restored from the stream.
So your serializable class does not need a no-argument constructor. Any non-serializable class it references must have one.
To answer the original poster's question: When you write the following Java code:
Object o = new Object();
the compiler generates the following bytecodes (comments added by me
The important thing to note is that the bytecode "new" allocates the storage for an object, but doesn't call the constructor. Then later on, the constructor is called by the bytecode "invokespecial". There's nothing to stop the deserialization code from creating an object and not calling the constructor -- it's just that the bytecode to do that can't be generated by a standard Java compiler. A bytecode "assembler" can do so easily!
The work of constructor is to initialize the state of the object.But as you are deserializing the object to restore its state to the value persisted in serialization the JVM will not call the constructor to initialize the state of the object.
Instead of this the readObject() method is responsible for reading and restoring the state of the object for its particular class using data written to the stream by writeObject() method.
State is restored by reading data from the ObjectInputStream for the individual fields and making assignments to the appropriate fields of the object.
The important thing is not to stop questioning.Curiosity has its own reason for existing.
Joined: Oct 11, 2005
That means, the object will be there in JVM, only it state is changed after de-serialization.
Tell me one thing, how the JVM can create object without calling constructor.
Is it possible to create object with out using the constructor in java?
Did you just make those classes and methods up? I don't think it helps matters to present a bunch of imaginary code as fact.
In any case, in my December 14th message I showed how, at the bytecode level, allocating an object and calling its constructor are two separate operations. In the Java language, you cannot allocate an object without constructing it, but the JVM can absolutely do so. Therefore it's clear that deserialization can proceed by executing JVM code that cannot be written in Java, but which can be executed on the JVM without any behind-the-scenes magic.
Although Thennanam Pandian states that he doesn't "think ... 'bytecode assembler' will participate at run-time," a bytecode generator absolutely does. Surely you've heard of Groovy, Scala, Clojure, and the many other languages that run on the JVM, all of which can generate and execute bytecode at runtime as they interpret the scripts you feed in? Serialization is not any different than this.
I somehow missed (or don't remember) this thread from back in December. It seems to have turned a bit nasty, though I'm not exactly sure why. We can keep it going awhile longer if there's still interest, but let's keep it civil, OK?
Ultimately, it does make an interesting point about what happens when you serialize something that implements Serializable but extends from a superclass that doesn't. Really, that's every time, since everything extends Object, and Object doesn't implement Serializable. I'm going to have to experiment with that a bit.
Pandian, you're calling a constructor directly, albeit through reflection, so that's the reason it's being called. Is that what you were asking?
By the way, EFH's reference was to Dionysus, whom Zeus sewed up into his thigh and whom was later "re-born" from there. Athena was also said to have been born fully-formed from Zeus's head, so Zeus had an unusual number of traumatic births for a father of that time. I guess when you're a god, though, you get used to weird ... stuff ... happening.