I said:
> 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.
Oh, now I remember these issues.
If you conservatively disallow all method calls (and other uses of
"this") before final assignments in constructors, then a lot of
subclass constructors become illegal. For example, without full static
analysis, you'd have to disallow the innocuous:
class Super {
Super() { f(); }
void f() { System.out.println("Hi!"); }
}
class X extends Super {
final int field;
X(int i) {
super();
field = i;
}
}
People would not be very happy about this.
Still, it seems like a bad idea to establish any sort of guarantees in
cases where people misuse finals. A disclaimer saying that all bets
are off if the non-assigned value of a final is ever accessed sounds
reasonable to me. Better static analysis tools could help programmers
avoid such cases.
-Doug
-------------------------------
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