final transient fields serialization

[Rémi Forax]

Le 10/11/2009 00:38, David M. Lloyd a écrit :
> On 11/09/2009 03:30 PM, Pawel Veselov wrote:
>> Hi,
>>
>> 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.
>
> I've used final transient fields before to hold values which are not 
> relevant on the remote side (and thus can be null or 0), but point 
> taken...
>
>> 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().

[...]

>
> - DML

Rémi