David Holmes wrote:
> Secondly, there must be some clear definitions for where "final field safe
> contexts" exist. The new JLS defines this term for places where reflective
> setting of final fields can be used safely/correctly, but nowhere (that I
> could find) in the JDK 5.0 documentation does it state what constitute
> "final field safe contexts" in that VM. In fact, it is worse than this - the
> JLS leaves it up to an implementation to define "final field safe contexts",
> so any such reliance on those contexts would be non-portable!
So, we introduced final field safe contexts as a sort of guarantee that
could be used in the future. The point was that if an API says "there
has to be a final field safe context here", there would have to be one
(regardless of what a VM thinks). If an API insists on it, it would
have to be there, or you wouldn't be able to implement the API.
It was also our intention to provide an API in "the next revision" (for
some value of "next") that would allow the user to specify a FFSC.
The point of this is that the wishy-washy language in the JLS about
leaving it up to the VM is just because the JLS doesn't specify APIs;
our language isn't anything to get too heated up over.
Once FFSCs have been established, it makes sense to say that you can
change final fields as long as you are in one.
As you say elsewhere, the relevant APIs need to be changed appropriately.
As a side note, we liked FFSCs as a solution because they also solved
another problem: an Executor that reads a finally field correctly can
legally see the wrong value for a final field if executed in the same
Thread as an Executor that read a final field incorrectly. This isn't
true if the Executor is in an FFSC. So Executors should also be in FFSCs.
In my dreams, sometimes I see myself going back in time and changing all
of the object construction semantics so these problems go away. :)
Jeremy
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:09 EDT