jQuery in Action, 2nd edition*
The moose likes I/O and Streams and the fly likes Safe to remove fields that are nulls? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » I/O and Streams
Bookmark "Safe to remove fields that are nulls?" Watch "Safe to remove fields that are nulls?" New topic
Author

Safe to remove fields that are nulls?

Xolani Nkosi
Ranch Hand

Joined: Apr 29, 2009
Posts: 32
I have some serialised objects from a class that looks like:

I have since decided that number needs to be a Long. I know that I can't just change it, as that will break deserialisation for my existing objects. So I do the following:

So now, newly made objects will exclusively use newNumber to store the value, and leave number null, and existing classes that I deserialise, get/set from, and then serialise again, will have their value copied over to newNumber.

My question is... is it safe to remove the Integer number field, once I know that all my stored objects have been migrated over to use the new field? e.g. does deserialision break even if the value it's attempting to set is null?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Seems to me it shouldn't take more than 15 minutes to do that experiment. Why not try it and see what happens?

Edit: and let us know what happens. Others may know the answer to your question but I don't and I'm sure many others don't either.
Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2833
    
  11

From what I know of serialization,

Any changes to the fields will change the serialVersionUID, and so make serialization impossible from "old" instances to "new", unless ...

You explicitly set the serialVersionUID, as you did, which effectively disables this check. By the way, you don't have to set it to such a cryptic number, unless you're trying to match it with a version of the class that didn't explicitly set the value. Normally, you can just set it to 0 or 1 or whatever. Not everyone knows that.

So, now we can serialize between different versions of the code:
Any member data that is present in the class available to the deserializer, but not in the serialized object will be set to a default value. (null, 0, or false)
Any values present in the serialized object, but not in the member data will be discarded.

So, I think that answers your question, but I agree with Paul that you should just run it through some tests. After all, my memory could be faulty, or serialization might have changed in the 14 years since I last looked into in that level of detail. Incidentally, you might look into the weird private methods readObject() and writeObject(). They can be useful for converting between different object versions. I'm not sure if they could help you in this case though.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Safe to remove fields that are nulls?
 
Similar Threads
nikos thread question
Niko's mock exam question
Validate method not completing
Struts2 QUERY Regarding Built in Type Conversions in Struts2 Framework
mismatch in printing the value of a variable