Serialization of Static Field

[andrepezzo]

Hi,
I have a simple class with 2 constructors.(It's very long so I won't paste it..).
I assign the value of a boolean static field according to the used constructor.
I also have implemented serialize/deser methods.

My problem is the following :
I have to perform different serialization/deserialization actions according to the constructor..so to the static field...but the static field doesn't preserve its value..
How should I do that??
How should I discrimine between them?

Thanks in Advance

[verruckt24]

Before moving further I would like to clear certain details. Since the static field would be common across multiple instances of a class, what if two different instances were initialized through diffrent constructors, in that case your serialization/deserialization would always depend on the last instance created. Would this be proper behaviour according to the logic of your problem or would not be ?

On second thoughts is this the question you are asking meaning is this what you mean by static field not preserving it's value ? (I have not clearly understood your question) if yes, then in that case you can use an instance variable instead of a static variable and have the serialization/deserialization behaviour depend on that.

[stephen84s]

Actually when you consider serializing static variables, it doesn't make any sense, because the static variables are part of the "STATE OF THE CLASS" not the "STATE OF THE OBJECT".

However as far as your question goes, any variable not declared as "transient" (even static variables) would be serialized and their state stored.

[andrepezzo]

I'll try to explain better :
when constructor "a" is called , and the boolean static var set to "true". Elsewhere with the constructor "b".
Differents objects are created in the 2 constructor , so I had to implement my custom ser/deser methods. Their behaviour depends on the flag set...

I'll try right now with the boolean flag without the static identifier...

[verruckt24]

Yes in this case you would have to use an instance variable for the flag instead of the static variable since, as pointed out in earlier posts static variable specifies a attribute of the entire class you won't be able to distinguish between two instances of the same class using it.

[~s.o.s~]

> any variable not declared as "transient" (even static variables)
> would be serialized and their state stored.

No, not really.

public class StaticTester implements Serializable {

  public static int gaga = 1;

  private int gogo;

  public static void main(String[] args) throws Exception {
    doTest();
  }
  
  private static void doTest() throws Exception {
    StaticTester t = new StaticTester();
    ObjectOutputStream oos = null;
    ObjectInputStream ois = null;
    File f = new File("o.ser");
    System.out.println("Static field before ser: " + StaticTester.gaga);
    try {
      oos = new ObjectOutputStream(new FileOutputStream(f));
      oos.writeObject(t);
    } finally {
      oos.flush();
      oos.close();
    }
    StaticTester.gaga = 999;
    System.out.println("Changed static field after ser: " + StaticTester.gaga);
    try {
      ois = new ObjectInputStream(new FileInputStream(f));
      t = (StaticTester)ois.readObject();
    } finally {
      ois.close();
    }
    System.out.println("Static field after deser: " + StaticTester.gaga);
  }

}
/*
OUTPUT:
[java] Static field before ser: 1
[java] Changed static field after ser: 999
[java] Static field after deser: 999
*/

[stephen84s]

However ~s.o.s~ if I am not wrong, every serializable class needs a static final long "serialVersionUID" field, which is used during deserialization (else the compiler throws (just) a warning), for checking if the class in memory and the serialized object match.

So I guess it must be an exception, to the normal rule.

[~s.o.s~]

> every serializable class needs a static final long "serialVersionUID"
> field

Yes, but static fields as a rule are not serialized by default. serialVersionUID is a special static field which is an indication to the serialization mechanism that 'persist the given instance with this version'. Even if a serialVersionUID is not provided, the serialization mechanism generates one based on the class structure / object hash code. Hence it would be a bit misleading stating that static fields are persisted when talking about serialVersionUID.

As long as no changes are made to the class, there is as such no problem ser/deser an object to persistent storage and retrieving from one with a default generated serialVersionUID. The problem arises when you make structural changes to the class which should in no way be treated as a different version [e.g. adding a method which has got nothing to do with ser/deser state of a class instance]. In this case, the serialization fails if a serialVersionUID field was not provided when defining the class.

So to cut long story short, don't think of serialVersionUID as a *static* variable stored to a persistent storage but as an indication to the serialization mechanism to *not* generate a default version number but use the one provided. To support this theory, every field persisted shows up in the serialized file i.e. if an object having instance variables "gogo" and "gaga" are persisted, the serialization file would show "gogo" and "gaga" with some other binary data; something which doesn't happen with serialVersionUID.