>
>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 Doug pointed out, this will break existing code. One problem is
that if you try to do the analysis for whether objects will escape
before there final fields are set, you find some cases where if
definitely will occur, and other cases where it only might occur.
Even figuring that out will require interprocedural analysis.
It also creates a fragile base class problems. What if you have final
fields, but your super class is changed to store a reference to
itself into the heap. Does your class now fail verification tests?
>
>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?
>
I'd be happy to hit them, but with what? I think they have to be
final, because you can't allow arbitrary code to modify them.
I haven't been able to find any code that actually invokes the setIn,
setOut and setErr functions, so I don't have a feeling for how
important that is. One suggestion would be to deprecate those
functions, and see who squeals.
Bill
-------------------------------
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