final transient fields serialization

[David Holmes - Sun Microsystems]

Pawel,

Pawel Veselov said the following on 11/10/09 07:30:
> it again caught my attention, and I though that may be there is 
> something that can be done about this.
> The issue is obvious -- having 'final transient' instance fields makes 
> little sense if the object is ever serialized.
> Logically, there may be perfect reasoning behind making an instance 
> field final, as well as transient, in which case there is then no 
> mechanism to reinitialize this field on object deserialization.

Not quite true. This problem - that final fields can only be set during 
true construction and not during the pseudo-construction that occurs 
during deserialization - has been realized for a long time. As part of 
the Java 5 update we (I think it was done JSR-133) put in place the 
mechanism whereby you can use reflection to set a final field provided 
that setAccessible(true) has been invoked for that field. This is of 
course a limited solution as you must have the security capability to 
invoke setAccessible(true).

JSR-133 also addresses the Java Memory Model issues concerning 
deserialization of objects with final fields - see Section 17.5.3 of the 
Java Language Specification. (The notion of a "freeze action" on a final 
field was in part motivated by the deserialization issue).

David Holmes

> It seems that it would be nice if either the final fields were 
> initialized in a separate block that would be executed on 
> deserialization, or if readObject() could set them. After all you can 
> have a code block that sets the final fields. Not sure how feasible that 
> is, but IMHO, that is a short coming.
> 
> -- 
> With best of best regards
> Pawel S. Veselov