 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2006Why it is dumb ideas to store permanent data in serialised files
I have heard people warn many times that serialised files are not suited for long term storage of data. I thought those warnings were exaggerated, until last night I decided to a add a long to one serialised class and convert from a 1.1 style enum to a 1.5. What a nightmare! I never would have guessed what a can of worms I was opening. It is kind of like pulling on a loose thread on sweater and watching the whole thing unravel before your eyes. For my caveats and approaches to handle the problem of updating serialised file formats see http://mindprod.com/jgloss/serialization.html#VERSIONING  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. It's an incredibly terrible idea to store long term data as serialised files. This is because in order to unserialise the file into a class, you must have a copy of the original class file. So if you make ANY changes to the class, the serialised class stored in the file will not be able to be restored using the changed class. Not if your class includes this: public static final long serialVersionUID = 1; /* Version 1 of the class */ This way you override the default serialVersionUID value which is formed from the totality of the class' method signatures by the JVM. Objects with serialVersionUID explicitly defined in the class will always be de-serializable, regardless of the changes between versions, and will span different Java releases. I've been using this technique for years, and my serialized objects, stores as blobs in DB, survived the transition from Java 1.2 to 1.5, with each and every release in between. Alex Molochnikov Gestalt Corporation > It's an incredibly terrible idea to store long term data as serialised > files. This is because in order to unserialise the file into a class, > you must have a copy of the original class file. So if you make ANY > changes to the class, the serialised class stored in the file will not > be able to be restored using the changed class. > Not if your class includes this: > > public static final long serialVersionUID = 1; /* Version 1 of the class */ You also need to make sure your new fields are marked transient if you want to be backward compatible with the old class structure. This is important if the data may need to be used on an old version of the program but is probably not be an issue if you're dealing with webapps. Richard You probably mean "forward compatible" - i.e. the old version of the class may have to be de-serialized from the data generated by serializing the newer version. The backward compatibility in serialization is not a problem - the new class, with added non-transient fields can always be de-serialized from an older version. In this case, the newly added fields will be set to the default values (0 for numeric primitive types, false for boolean, null for anything that is an object). > > Not if your class includes this: > > [quoted text clipped - 6 lines] > > Richard > You probably mean "forward compatible" - i.e. the old version of the class > may have to be de-serialized from the data generated by serializing the > newer version. That's exactly what I meant, Richard On Sun, 12 Feb 2006 20:30:29 GMT, "Alex Molochnikov" <NOBODY@NOSPAM.COM> wrote, quoted or indirectly quoted someone who said : >You probably mean "forward compatible" - see http://mindprod.com/jgloss/compatibility.html http://mindprod.com/jgloss/forwardcompatibility.html http://mindprod.com/jgloss/backwardcompatibility.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > I have heard people warn many times that serialised files are not > suited for long term storage of data. I thought those warnings were [quoted text clipped - 10 lines] > serialised file formats see > http://mindprod.com/jgloss/serialization.html#VERSIONING There is an additional reason, beyond the class maintenance issue. One may want to access permanent data from another language, on a different system, at some time in the future. Consider, for example, the number of times people needed to read Fortran binary files in C programs as C became more popular. For that to work smoothly, the file layout and encoding of the data should be defined, simply and directly, in a language-neutral way. It is hard to imagine anything less language-neutral than serialization. Patricia Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.