Pawel,
Sorry for the late followup, but you might also want to read these RFEs:
http://bugs.sun.com/view_bug.do?bug_id=6379948
http://bugs.sun.com/view_bug.do?bug_id=6252102
-- Peter
On Nov 9, 2009, at 6:54 PM, David Holmes - Sun Microsystems wrote:
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
