At 07:19 AM 3/03/2004 -0500, Doug Lea wrote:
>While it seems too late to do anything about this for JDK1.5.0, it is
>still worth thinking about how to safely allow reestablishing
>transient final fields during deserialization. Otherwise people will
>still not use final when they otherwise should.
>
>The only idea I've ever had about this always seemed too ugly, messy,
>and slow to actually carry out, but now seems more plausible:
>
> Change java.lang.reflect support to allow a reflective Field.setX (X =
> Short, Float, etc) for a final field of an object currently being
> deserialized.
>
>In principle, this seems possible: the reflection and security
>mechanisms can detect if the write can be safely allowed, and if it
>is, the write can be done using "volatile" semantics, which would
>suffice wrt JMM guarantees.
>
>Can anyone think of alternatives?
The readObject() method could be given special status if it's private and
not invoked from within the class. It could then be treated as if it were a
constructor, and be allowed to make the required assignment. Of have I
missed the point?
Sylvia.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:58 EDT