At 07:56 AM 4/03/2004 -0500, 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.
What I had in mind was that constructors cause no particular difficulty in
this respect, so why not elevate readObject to the status of a constructor
in the special circumstance where it could only be called by reflection
either from within the class (an odd concept) or from elsewhere with access
controls bypassed. This situation is recognisable both by javac, and by the
JIT.
It's rather ad-hoc, but the alternative of requiring transient final fields
to be set by reflection seems so heavyweight (and cumbersome to code) that
programmers would avoid making transient fields final except where this was
necessary for security (and the programmer understood the issue!). I would
prefer the situation where people made fields final unless they needed to
be set more than once.
Evan, regarding readExternal and writeExternal, I imagine your concern is
that they don't fit into this model because they obviously have to be
public (and so could be called from anywhere at any time), and constructors
(the no-arg public ones) have already been called. I suppose Doug's
reflection approach would have to be used here.
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:59 EDT