• Post Reply Bookmark Topic Watch Topic
  • New Topic

help for serialization with final member  RSS feed

 
Pat Farrell
Rancher
Posts: 4686
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've got a class that I'm trying to write manual serialization code. I can't figure out how to handle the "final Person" member.
I can't do a set in the readObject function, since its final



I don't want to let the default implementation of readObject do its thing, because I don't want to serialize the whole Person, I'd rather just serialize its primary key (a Long) and recreate it on the fly. This is to avoid getting into a serialization loop, as a Person has a SmartList, which contains a reference to a Person, who has a SmartList....

How do I do this?

thanks
pat
 
Leandro Coutinho
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You said that Person has a SmartList. So to avoid the serialization loop, set the SmartList in the person object to null.
I think it will work.
 
Pat Farrell
Rancher
Posts: 4686
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Leandro Coutinho wrote:You said that Person has a SmartList. So to avoid the serialization loop, set the SmartList in the person object to null.

I don't want it to be null, I want to have values in it.

So I need to be able to assign values in the readObject class to variables that are final.
This seems to be impossible.
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wait until somebody like Rob Prime is around, who will probably know how to use the readResolve method for that.
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually I don't...

You can disable the default serialization of a field, either by making it transient or by explicitly specifying the ObjectStreamFields, but both will not restore it when deserializing. Since the field is final that means it will remain null indefinitely.

Perhaps you can get some results using writeReplace and readResolve as Campbell suggested; I haven't got much experience in these except for using the latter for maintaining Singleton instances properly for Serializable classes. Or perhaps it's even easier using readObject and writeObject; if you simply do not call stream.defaultReadObject and stream.defaultWriteObject it will not use the default serialization mechanism but your custom serialization instead. However, the final member will not be deserialized and will remain null...

Frankly, final fields and custom serialization are often a pain to combine, and often you need to drop one of the two.


However, Pat, you do realize that objects will not be serialized more than once, even if more references to it are serialized? The serialization mechanism will detect the object has been serialized already, and will store a reference to that serialized object instead of the object itself.
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If Rob doesn't know, it must be difficult. There is a serialization section in Effective Java, 2nd edition, try page 302. It is too long to copy, but it goes on about defensive writing of readObject methods. It does not suggest there is any problem about serialising with final fields.

I have no idea whether this is of any use to you, or a waste of time. Sorry.
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:If Rob doesn't know, it must be difficult.

You give me too much credit.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!