Can we treat final reorder rule in Java as happens-before rule?

Question

There exist two final record rules in Java, as follows:

1. a write to final field in constructor and the constructed instance reference is assigned to variable afterwards can not be reordered
2. read a instance reference and read the final field in the instance afterwards can not be reordered

Can we treat above rules as happen-before rules?

1. a write to final field in constructor happens-before the constructed instance reference is assigned to variable afterwards
2. read a instance reference happens-before read the final field in the instance afterwards

I think happens-before rule is stronger semantic.

Answer 1

In my understanding finally,the semantic guarantee of final keyword and happens-before rule belong to separate categories.The above derivation is wrong and unnecessary.

Answer 2

I think happens-before rule is stronger semantic.

The final reordering rule is definitely stronger, in this context:

• The happens-before rule does not forbid reordering of statements locally provided that the behavior after reordering is sequentially consistent; i.e. solely from the perspective of the thread creating the object.

• By contrast the final reordering rule does expressly forbid certain reorderings within the constructor, in addition to those the would violate sequential consistency.

Corollary: the HB doesn't subsume the final reordering rule.

^{(If it did, then it wouldn't be necessary state the latter at all. But the JLS authors don't add that stuff just for the heck of it. Give them and the thousands of other people who have read / studied this stuff some credit.)}

---

It is a design goal that it should be possible to use a final field from any thread without any explicit synchronization or memory model related performance overheads; i.e. no memory barriers for reads.

If local reordering for a final fiels was permitted in the constructor, then another thread would need a memory barrier to ensure that it saw a consistent value for the affected field. I can't think of a practical way to optimize that away. The potential small impact of not reordering in a constructor is (on average) less than the impact of read barrier for every read of the field.