• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How the objects are constructed at the time of de-serialization?

 
Thennam Pandian
Ranch Hand
Posts: 163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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. )
 
Joe Ess
Bartender
Pie
Posts: 9266
10
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thennam Pandian wrote:But at the time of de-serialization, the object constructor won't be called.


Why does java.io.Serializable require a no-argument constructor if it will not call it?
 
Thennam Pandian
Ranch Hand
Posts: 163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am sure, it won't call default constructor.

Have tried this, by printing some message in the default constructor itself. But the message is not printed at the time of
de-serialization.



 
Joe Ess
Bartender
Pie
Posts: 9266
10
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thennam Pandian wrote:I am sure, it won't call default constructor.


I misspoke:

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.
 
Rob Spoor
Sheriff
Pie
Posts: 20512
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Again incorrect. Only the first non-serializable super class must have one. Any fields in any serializable class must be a) serializable as well, or b) transient.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Thennam Pandian
Ranch Hand
Posts: 163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!


De-serialization happens at run-time. Also all the objects are created in run time.
I don't think "standard Java compiler" or "bytecode assembler" will participate at run-time.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thennam Pandian wrote:
De-serialization happens at run-time. Also all the objects are created in run time.
I don't think "standard Java compiler" or "bytecode assembler" will participate at run-time.


Yes, you're right. The code that performs deserialization springs, via an occult process, fully formed from the thighs of Zeus.
 
Thennam Pandian
Ranch Hand
Posts: 163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ernest for your response.

Could you please explain your previous response, I didn't get you ?
 
Vijay Tidake
Ranch Hand
Posts: 148
Hibernate Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

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.

Thanks
 
Thennam Pandian
Ranch Hand
Posts: 163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

 
Vijay Tidake
Ranch Hand
Posts: 148
Hibernate Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The object will not be in JVM.

At the time of deserialization JVM creates the object and and initialize the state of object with the serialized values.

JVM do this stuff by means of Reflection.

This how it must be working.Following code creates the object of a class without calling the constructor of it.

In following code the object of class A is created without calling its constructor.
The same or other kind of mechanism they must be using while deserializinng the object.


The programs produces the output like "My Info::I am demo.A@55f33675"


Hope this will help you

Thanks
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
vijay --

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.
 
Vijay Tidake
Ranch Hand
Posts: 148
Hibernate Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ernest,

Thanks for the more information
 
Thennam Pandian
Ranch Hand
Posts: 163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the reply and the code you have shared is not calling constructor.

But the following code calls the constructor.

Let me know, if you know the reason.

 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Unsubscribing from this thread. Bye!
 
Greg Charles
Sheriff
Posts: 2985
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic