Dan Bornstein wrote:
> 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 spec does state that fields with an access flag of ACC_FINAL may
have "no further assignment after initialization". You could take that
as the absolute defining rule.
But the enforcement of that in putfield and putstatic is simply to
check that the field is defined in the current class - which is a
necessary, but by no means sufficient, condition for the
putfield/putstatic being done in an initialization context.
Arguably the spec does prohibit changes to final fields, but relies to
a great extent on the compiler for enforcement of that.
> 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.
Usually such things are handled by native code and JNI does not
require that a "set field" honour the ACC_FINAL flag.
System.setXXX were a really bad idea that we're now forced to live
with. Hence the special treatment within JSR-133. (And I wonder if the
lack of JNI support for final's came about when someone realized they
wouldn't be able to to implement setXXX if JNI did the "right thing" )
Arguably, deserialization can be defined as a form of initialization
and so it is allowed to set final fields - and I consider it a
weakness that the langauge itself can't support this. There must then
be a means to effect this. But note that trying to do this in bytecode
would typically fail because defaultReadObject is not part of the
current class and so can't write to the final field as per the
requirements of putfield/putstatic.
I think the only conclusion to draw from this is that the VM spec
needs clarifying and/or tightening in this area.
YMMV.
David Holmes
-------------------------------
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