I starting thinking about the semantics of serialization and final
fields; it is ugly.
When an object is being restored from a serialized form, the
constructor that would normally set the final fields isn't called.
Instead, the value of the final field is set by the de-serialization
code.
Some questions/issues:
* It is apparent that the defaultReadObject function can set final fields.
It would seem that if you
- used your own readObject method (without calling defaultReadObject),
- used serialPersistentFields
- used the Externalizable interface
it is _impossible_ to set final fields. Does anyone disagree? This
might prove to be a drawback to using final to handle the
immutability problem; sometimes you can't use it because you want to
have your own custom Serialization scheme.
* Whatever special status we grant to constructors and/or final
fields (if any) should (in my opinion) also apply to instances that
have been de-serialized. Which means that we are going to need to
talk about defaultReadObject and readObject in the formal
specification of the memory model. Yuck!
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:18 EDT