Is there a limit to overriding final static field with Reflection?

Question

I have been faced in some of my Unit test with a strange behaviour with Reflection on final static field. Below is an example illustrating my issue.

I have a basic Singl

Answer 1

It's because of the JIT optimization. To prove this, disable it using the following VM option:

-Djava.compiler=NONE

In this case all 10_000 iterations will work.

Or, exclude the BasicHolder.getVALUE method from being compiled:

-XX:CompileCommand=exclude,src/main/BasicHolder.getVALUE

What actually happens under the hood is that after nth iteration, the hot method getVALUE is being compiled and static final Integer VALUE is being aggressively optimized (this is really the just-in-time constant¹). From this point, the assertion starts to fail.

The output of the -XX:+PrintCompilation with my comments:

val 1       # System.out.println("val " + BasicHolder.getInstance().getVALUE());
val 2
val 3
...
922  315    3    src.main.BasicHolder::getInstance (4 bytes)   # Method compiled
922  316    3    src.main.BasicHolder::getVALUE    (4 bytes)   # Method compiled
...
val 1563    # after compilation
val 1563
val 1563
val 1563
...

---

^{1 - JVM Anatomy Park: Just-In-Time Constants.}

Answer 2

The JLS mentions that modifying final fields after construction is problematic - see 17.5. final Field Semantics

Fields declared final are initialized once, but never changed under normal circumstances. The detailed semantics of final fields are somewhat different from those of normal fields. In particular, compilers have a great deal of freedom to move reads of final fields across synchronization barriers and calls to arbitrary or unknown methods. Correspondingly, compilers are allowed to keep the value of a final field cached in a register and not reload it from memory in situations where a non-final field would have to be reloaded.

and 17.5.3. Subsequent Modification of final Fields:

Another problem is that the specification allows aggressive optimization of final fields. Within a thread, it is permissible to reorder reads of a final field with those modifications of a final field that do not take place in the constructor.

In addition to that, the JavaDocs of Field.set also include a warning about this:

Setting a final field in this way is meaningful only during deserialization or reconstruction of instances of classes with blank final fields, before they are made available for access by other parts of a program. Use in any other context may have unpredictable effects, including cases in which other parts of a program continue to use the original value of this field.

It seems that what we are witnessing here is the JIT taking advantage of the reordering and caching possibilities granted by the Language Specification.