> On Tue, 30 Sep 2003 1:23 pm, Bill Pugh wrote:
> > The rules on final fields being set exactly once are part of the
> > JVM/classfile specification.
>
> Actually, they're not. Per the VM spec, "final" fields are read-only to
> most classes but read-write at any time to the defining class itself.
The VM Spec has a little to say on this (Section 2.9.1):
Once a final field has been initialized, it always contains the same
value.
We are clarifying this (significantly) in JSR-133. From the community
draft:
A final field may only be written by bytecode once. Other techniques,
such as deserialization, may cause a final field to be modified after
the end of the enclosing object's constructor.
I recommend that anyone interested in the proposed semantics of final
fields look over the relevant sections in the community draft of 133:
http://www.cs.umd.edu/users/pugh/java/memoryModel/CommunityReview.pdf
and in a more detailed document, solely on final fields:
http://www.cs.umd.edu/users/pugh/java/memoryModel/newFinal.pdf
> It's worth noting that the implementations of System.set{In,Out,Err}
> effectively make use of this difference, as does the entire
> serialization system.
The difference is that none of those mechanisms use bytecode to change
final fields. The semantics of those mechanisms are discussed in detail
in the documents as mentioned above.
Basically, the new semantics provide for thread-safe immutability while
also allowing for signficant optimizations (including the ones mentioned
earlier in this thread) and for serialization to change final fields.
The semantics closely track the discussions that have evolved on this list
in the past. We greatly value input on these documents, and I strongly
recommend that anyone who has to deal with final fields familiarize
themselves with them.
Jeremy
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:51 EDT