Sylvia wrote:
> 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?
Because the calling context of readObject required here is not a
static, syntactic property, the final-field set would need to be done
using reflection, so it can be dynamically checked.
This is not quite logically forced -- you could have special rules for
compiling final field assignments -- but no other assignment operation
in Java requires a stack-trace-based check of this form. Reflection
operations in general do. So as a practical matter, fitting it in via
special handling of Field.setX for "transient final" fields seems to
be the only plausible approach.
Also, doing it via reflection rather than special rules for
assignments would convey that this is not usually a cheap operation
like normal assignments are. Deserialization is itself usually not all
that cheap, so the performance can probably be tolerated here,
considering the alternative of not being able to do this at all.
Doran wrote:
> What if someone access that field?
Under the checked context, no other thread can have obtained a
reference to object being deserialized. As long as the readObject
method itself doesn't leak it (i.e., the same bad cases as apply to
constructors), I think that all is well wrt other JMM rules.
...
Given the encouraging replies I've gotten by people needing something
like this, I'm going to further investigate whether and how this can
be done.
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:59 EDT