final transient fields serialization

[Peter Jones]

On Nov 10, 2009, at 2:30 AM, Rémi Forax wrote:
> Le 10/11/2009 00:38, David M. Lloyd a écrit :
>> On 11/09/2009 03:30 PM, Pawel Veselov wrote:
>>
[snip]
>>> 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.
>>
>> One possible problem with this is that changing a final field might  
>> have some JMM implications (case in point, CopyOnWriteArrayList  
>> uses sun.misc.Unsafe#putObjectVolatile() to reinitialize the  
>> transient final Lock field, though I don't see anywhere that  
>> ObjectInputStream itself takes such precautions; one would think  
>> that java.lang.reflect.Field would take care of this for you, but  
>> perhaps it does not).
>
> It does :)
> Chnaging a volatile or a final field by reflection is done with a  
> put...Volatile().

Yes for java.lang.reflect.Field, but David's comment reminds me of  
this bug:

http://bugs.sun.com/view_bug.do?bug_id=6647361

which I'm somewhat embarrassed to have neglected after filing...

-- Peter