final transient fields serialization

Peter Jones pcj at
Sun Nov 29 21:05:43 UTC 2009


Sorry for the late followup, but you might also want to read these RFEs:

-- 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

More information about the core-libs-dev mailing list