Final instance fields have special memory model rules that apply "when determining which values can be seen by" a read operation. These rules ensure that, for an object that was properly shared with the current thread after a "freeze" action at the end of a constructor, values that were held earlier by the field, but were overwritten before the "freeze", cannot be observed. Most commonly, this means that the read cannot observe the final field's default value.

The same principle should apply to all strictly-initialized instance fields (final and non-final, including the fields of value classes): any values of the field that were overwritten before a "freeze" action cannot be observed by reads in other threads.

Two differences from non-strict final fields:

- The "freeze" action happens at the point of a 'super()' call (or equivalently, on entry to the Object superconstructor)

- The object will *always* be "properly shared" with other threads, because it cannot be shared before the "freeze" action.

The specification for the final field behavior today (17.5.1) is messy and appears to be buggy. One move I think would be helpful is to abandon the idea of defining a new happens-before edge that "does not transitively close with other happens-before orderings". It doesn't really make sense to frame it in this way, and the new edges should just be given a different name. These new edges only seem to impact the "allowed to observe" relation defined in 17.4.5, so there's room for some renaming/refactoring here.

Fortunately, the complex rules in 17.5.1 about when an object is "properly shared" are not relevant to strict fields, and can probably be left alone.