RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods
vladimir.x.ivanov at oracle.com
Tue Jun 14 12:17:10 UTC 2016
>> Also, have you run the JCK tests?
>> Why have a global flag if it's an error?
> We are enforcing a rule that has not been enforced before. To deal with
> compatibility issues we have provided, as is customary for non-security
> issues, a flag that allows the enforcement to be turned off, if it
> causes a problem. (Though that is more likely needed for JDK 7/8
> compatibility than for 9).
FTR I'd like to see the checks turned ON by default for 7/8 in 9 and the
flag providing an escape hatch for compatibility purposes.
It is motivated by the desire to limit possibilities of final field
updates at runtime, so JIT-compilers have more freedom optimizing loads
from final fields. It will be unfortunate if we effectively forbid final
field updates outside of initializers starting only from 9 (class files
>=53) and not 7 (cf >=51).
The change requires a CCC request and will be investigated separately
If there are serious compatibility issues found during EA testing, we
can turn the checks OFF by default.
The flag is declared as diagnostic, so I don't think we need to go
through deprecation process (as we do for product flags) and just remove
it in the next(?) major release.
More information about the hotspot-compiler-dev