Jerry Schwarz wrote:
> If you want to do this you need to be much more specific
> about exactly what you want to reject. It's important that
> all verifiers follow the same rules.
>
> For example, the rules should not reject
>
> class X {
> final int x;
> X(int cond) { if ( cond > 0 ) { x = 1; } else { x = -1; } }
> }
Can the rule simply be that any assignment to a final field must occur
in a constructor or initializer? It's easy enough to tell if you're in
a constructor. My only concern is how initializers are compiled -
javac seems to inline them into the constructor body but I'm not sure
if that is the required form.
This simple rule would still allow code that wouldn't pass the Java
Language rules for finals, but hopefully is adequate for JMM purposes.
Bill Pugh wrote:
> >If not, do we have to say what the semantics are for
> >classfiles that violate this rule, or can we simply leave it
undefined?
Is it sufficient to simply say that any such setting of the final
field (just as if done by JNI) may not be seen by code that reads/uses
the final field?
A stale value would always be safe from a VM perspective.
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:56 EDT