final transient fields serialization
pcj at roundroom.net
Sun Nov 29 21:05:43 UTC 2009
Sorry for the late followup, but you might also want to read these RFEs:
On Nov 9, 2009, at 6:54 PM, David Holmes - Sun Microsystems wrote:
> 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
More information about the core-libs-dev