This discussion is archived
7 Replies Latest reply: Jun 21, 2011 7:58 AM by 802316 RSS

Customize the Default Protocol in Serialization?

866541 Newbie
Currently Being Moderated
Going thru the serialization article at [http://java.sun.com/developer/technicalArticles/Programming/serialization/] . Topic is Customize the Default Protocol+
As per my understanding when we try to read an serialized object(during desrialization) at server , new object will be created at serverside with same values of instance variables lying in serialized object. Right?
But there is paharagraph under topic Customize the Default Protocol at shred link. it says

All seems fine until we read the object back in with a call to the readObject() method. Remember, a constructor is called only when a new instance is created. We are not creating a new instance here, we are restoring a persisted object. The end result is the animation object will work only once, when it is first instantiated. Kind of makes it useless to persist it, huh?

As per me here also new object of PersistentAnimation will be created during desrialization process with the same state as in serialized object. So whats the issue here in readObject() method? it says We are not creating a new instance here, we are restoring a persisted object. Yes we are creating the new instance here but with the same values of instance variable that is there in serialized object. where the statement coming from object will work only once, when it is first instantiated. Kind of makes it useless to persist it, huh?
  • 1. Re: Customize the Default Protocol in Serialization?
    EJP Guru
    Currently Being Moderated
    So what's the issue here in readObject() method?
    The issue is that it doesn't call any constructors of the serialized object.
    where the statement coming from +object will work only once, when it is first instantiated.
    It applies to the specific class the author is talking about, where the constructor does something about making the object work, i.e. starts a new thread, as discussed in the article, about two inches above the part you quoted.
    Kind of makes it useless to persist it, huh?+
    Only if you misread the article so completely as to think that a remark about a specific class applies to everything in the universe.
  • 2. Re: Customize the Default Protocol in Serialization?
    866541 Newbie
    Currently Being Moderated
    The issue is that it doesn't call any constructors of the serialized object.
    But Deserialization will create a new object (probably with a new operater or class.newInsatnce()) in server jvm with same values of instance variables lying in serialized object. Right?
  • 3. Re: Customize the Default Protocol in Serialization?
    EJP Guru
    Currently Being Moderated
    But Deserialization will create a new object
    Correct.
    (probably with a new operater or class.newInsatnce())
    Incorrect. Either of those would call a constructor. Serialization doesn't call any constructors of the Serialized object. The article you cited says that. I said that.
  • 4. Re: Customize the Default Protocol in Serialization?
    866541 Newbie
    Currently Being Moderated
    But Deserialization will create a new object
    Correct.
    (probably with a new operater or class.newInsatnce())
    Incorrect. Either of those would call a constructor. Serialization doesn't call any constructors of the Serialized object. The article you cited says that. I said that.
    HI EJP as per above, Deserialization will create a new object but not with new operater or class.newInsatnce(). But whats the other way to create the object?
  • 5. Re: Customize the Default Protocol in Serialization?
    DrClap Expert
    Currently Being Moderated
    It's a secret way which is available to the deserialization code but not to you as an application programmer. What difference does it make to you?
  • 6. Re: Customize the Default Protocol in Serialization?
    796440 Guru
    Currently Being Moderated
    Note that the usual and recommended way of implementing clone() also does not invoke any constructor.
    public class C implements Cloneable {
      public static void main(String... args) throws Exception {
        C c1 = new C();
        C c2 = C.class.newInstance();
        C c3 = c1.clone();
      }
      
      public C() {
        System.out.println("C'tor!");
      }
    
      public C clone() throws CloneNotSupportedException {
        return (C)super.clone();
      }
    }
    All this is generally fine, because a c'tor is not supposed to perform any business logic. It's only supposed to get a newly created object into a valid state. Cloning and serialization are not about creating new objects. They're about preserving and restoring or duplicating the state of an object that's already fully functional.

    Note also, that if you do end up needing to perform some other logic as part of deserialization or cloning, you can do so. These cases should be the exception, not the rule.
  • 7. Re: Customize the Default Protocol in Serialization?
    802316 Pro
    Currently Being Moderated
    DrClap wrote:
    It's a secret way which is available to the deserialization code but not to you as an application programmer.
    As it a "secret" way which is for internal use only, it differs for different JVMs.

    If you want to know more, I suggest you read the source code which comes with your JDK.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points