Doug Lea wrote, quoting Bill Pugh:
> > public class A {
> > final int x;
> > static A I(A a) { return a; }
> > A() {
> > A a = I(this);
> > int i = a.x;
> > this.x = 42;
> > int j = a.x;
> > }
> > }
> > In looking at the constructor for A, it seems that
> > we should be able to replace the second read of a.x
> > with a reuse of the previous loaded value; after all,
> > a.x is final and cannot change.
> >
> > But of course, in this case, it can.
>
> My take on this is that language/vm treatment of final are too weak.
> I think this code compiles and loads due to limitations in the
> compile/verify checks, not by any other intent. Probably the best
> solution would be to fix the compiler and verifier (and their specs)
> to be more conservative here, outlawing all potential reads before
> writes of finals -- which would in particular disallow all non-static
> method calls on this before values are set.
I very strongly agree with Doug here. The rules in the VM/verifier for
when the superclass constructor must be called in a constructor could
apply equally well to when final instance variables must be assigned.
As for the abomination that System.in, System.out, and System.err are
final but can be changed, as long as we're changing specs, why not hit
at that one, too?
--p
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:19 EDT