Author Topic: serial version uid  (Read 2881 times)

Offline raft

  • quad
  • ******
  • Posts: 1966
    • View Profile
    • http://www.aptalkarga.com
serial version uid
« on: November 02, 2005, 02:00:08 pm »
egon, can u please add a serial version uid to serializable classes ? it becomes incompatible with the previous version and it breaks loading previously serialized objects. sun suggests it too and it wont hurt for sure

Code: [Select]
private static final long serialVersionUID = 999L; // or whatever long

of course you can change it in time when it is necessary (such as when internal fields are not backward compatible)

and when did you update the site, i must have missed it. it looks nice :wink:

Code: [Select]
r a f t

Offline rolz

  • float
  • ****
  • Posts: 280
  • Technocrat
    • View Profile
serial version uid
« Reply #1 on: November 02, 2005, 05:21:58 pm »
Yay. The new site looks awesome !
Regards,
Andrei

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11748
    • View Profile
    • http://www.jpct.net
Re: serial version uid
« Reply #2 on: November 02, 2005, 10:44:44 pm »
Quote from: "raft"
and when did you update the site, i must have missed it. it looks nice :wink:
Yesterday... :wink:

About the ID: I thought about that but isn't the result the same? I.e. you can't deserialize old stuff with a changed class. I'm asking because i've never used it. I just serialized all the required instances again after making a change. So where is the actual difference?

Offline raft

  • quad
  • ******
  • Posts: 1966
    • View Profile
    • http://www.aptalkarga.com
Re: serial version uid
« Reply #3 on: November 03, 2005, 05:56:18 am »
Quote from: "EgonOlsen"
you can't deserialize old stuff with a changed class. So where is the actual difference?

you can, even if you changed the class incompatibly. you can change method names, signatures even add new fields (they are simply set to nulls or zeros during deserialization). i'm not sure what happens if you change field types or remove a field but the others dont break deserialization

Code: [Select]
r a f t

Offline rolz

  • float
  • ****
  • Posts: 280
  • Technocrat
    • View Profile
serial version uid
« Reply #4 on: November 03, 2005, 09:51:11 am »
from the javadocs:

Quote

 The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException. A serializable class can declare its own serialVersionUID explicitly by declaring a field named "serialVersionUID" that must be static, final, and of type long:

 ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;
 

If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification. However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class--serialVersionUID fields are not useful as inherited members.


  From what i have managed to learn so far - if you do not add/remove fields to the class then it is good idea to explicitly define serialVersionUID to keep compatibility with previous classes. This means you can add/modify methods as much as you wish without worrying for compiler to recalculate serialVersionUID on _any_ change.
  If you add/remove fields then you will get InvalidClassException anyway.
Regards,
Andrei