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
