At 04:56 AM 3/4/2004, Doug Lea wrote:
>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.
I agree with Sylvia that all we need to do is change the definition of
"definitely unassigned" in the JLS to make a special case for readObject.
As it stands I believe the "one assignment" for finals is enforced by the
compiler but not checked by the verifier.
I don't have the tools to do it, but I think you can compile a class in
which field x isn't final and there are lots of assignments to it, zap the
.class file so that x is final, and use the class. Perhaps someone with
the tools to try this easily could run the experiment and let us know the
results.
A while ago I proposed that the JMM be adjusted to take into account what
happens if a final field gets assigned to twice, but that suggestion wasn't
accepted.
>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
-------------------------------
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